Re: [Linux Memory Hotness and Promotion] Notes from July 30, 2026

On Sat, 1 Aug 2026 20:40:35 -0700 (PDT) David Rientjes <[email protected]> wrote:

> Hi everybody,
> 
> Here are the notes from the last Linux Memory Hotness and Promotion call
> that happened on Thursday, July 30.  Thanks to everybody who was involved!
> 
> These notes are intended to bring people up to speed who could not attend 
> the call as well as keep the conversation going in between meetings.

Thank you for sharing this note, David.  This is so helpful!

[...]
> Bharata updated on the status of his v8 patch series.  He has posted it 
> with some numbers and did not observe any regressions when comparing NUMAB 
> with pghot.  The initial goal is to upstream the support for the tiering 
> subsystem regardless of the number of page hotness sources.  Thus, the 
> upstreaming story will be about clean up and refactoring to support 
> tiering; David Hildenbrand had suggested that the current approach was too 
> extensive.
> 
> Bharata was also looking into performance numbers asynchronously.  Gregory 
> had been vocal on why this patch series is needed upstream, but any 
> additional use cases and support for the upstream series would be 
> beneficial.
> 
> ----->o-----
> There was discussion about what overlap this work had with DAMON.

I should have attended the meeting, sorry.  I show some rooms to improve
clarifications.  Let me add a few comments.

> DAMON 
> was noted as being highly complex

I admit there are many complicated parts in DAMON.  We therefore actively
working on this.  We develop auto-tuning and simplified alternative features
for users.  We cleanup and refacor the code for developers.

It would be nice if I could further learn what makes people feel this way, and
wht can we change in DAMON to make it simplified.

> and we reflected on previous examples 
> where this was a similar story upstream.  Wei suggested that memory 
> tiering should be supported in the core MM and not something external.

I think this could better be clarified.  What is the definition of core MM, and
why it is beneficial to have the support inside it?

> He 
> also suggested that we wanted to support hotness signals from hardware 
> (like CHMU) and fix the promotion side but that does not require extending 
> DAMON specifically.  Nobody in the call suggested that they were working on
> productionizing DAMON at this time.

We shared the plan [1] to extend DAMON for multiple access primitives (a.k.a
source) other than page table accessed bit in LSFMMBPF'25.  A few people showed
interest.  Amazon and Micron publicly showed their interest.  There were few
more companies showed interest offline.  We therefore kept working on it.
Recently a concrete plan with timeline [2] is made, and we are working on it.
Quite amount of preparational changes are already upstreamed and working
prototypes are shared.

> 
> Gregory suggested that our focus should be on generic support in the 
> kernel that ensures that we can handle these memory topologies correctly 
> and without extensive configurations, including from userspace.  Wei 
> strongly agreed with this.

I fully agree with this.  I shared my plan [3] for doing that for not only
tiering but general NUMA topologies in LPC'25.

I will try to join the next call for more conversations.  But feel free to ask
any questions on the mailing list or privately to me, at anytime.

[1] https://lwn.net/Articles/1016525/
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lpc.events/event/19/contributions/2066/


Thanks,
SJ

[...]