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

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

[David Rientjes]

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.

----->o-----
Yiannis updated on the status of non-temporal stores and working with 
Huan's patches to handle memory errors.  Yiannis preferred Huan's 
implementation and would like to fold that into the patch series.  He also 
added the Kconfig that we had discussed in the last meeting.

Huan asked if we also need to support ARM; Wei noted that in the latest 
upstream kernel that there was a switch in instructions so non-temporal 
stores is actually the default now for ARM.  Wei suggested applying Huan's 
series on top of Yiannis's patch series and Yiannis agreed.

We agreed that the patch series should be combined into a single series.  
Yiannis will do this over the next few days and then will be going on 
leave (congratulations!).

----->o-----
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.  DAMON 
was noted as being highly complex 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.  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.

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.  Bharata had replied to Andrew along the same 
lines as this and he suggested that we should provide this feedback 
directly on the mailing list.

Yiannis said what is missing from the discussion is that this support will 
be a major use case for the kernel and that feedback needs to come from 
the hyperscalers.

----->o-----
Shivank updated on v6 of his work.  He had received some feedback upstream 
but there is nothing blocking.  He also updated the SDXI support on his 
upstream repository.  He will also post the rmap batch support upstream 
which will help with mTHPs[1].

Teja asked if there were any hardware issues that were encountered in the 
testing of this series like he had seen.  He saw vendor specific errors 
that were logged.  Shivank suggested that Teja can send him the hardware 
errors to look deeper.

----->o-----
Joshua quickly updated on the status of tier-aware memcg limits.  Based on 
feedback, he is pivoting to supporting N-tiers from the very beginning 
instead of only two.  Additionaly, in the first iteration nothing will be 
exposed to userspace, all of it will happen transparently.  The goal is to 
upstream the mechanism first as discussion continued.

----->o-----
Next meeting will be on Thursday, August 13 at 8:30am PDT (UTC-7),
everybody is welcome: https://meet.google.com/jak-ytdx-hnm

Topics for the next meeting:

 - update on combined patch series for supporting non-temporal stores in
   migrate_pages() with memory error handling (series from Yiannis +
   Huan)
 - v8 of Bharata's patch series and next steps for clean up and
   refactoring to support the initial landing
 - v6 of Shivank's series for enlightening migrate_pages() for hardware
   assists and his rmap batch series
 - v2 of tier-aware memcg limits, including ABI changes to support more
   than two tiers
 - Gregory's investigation into demotions for multi-tiered systems and
   LRU inversions
 - first class support for virtualization based memory tier support, how
   to leverge memory tiers in the guest
 - discuss generalized subsystem for providing bandwidth information
   independent of the underlying platform, ideally through resctrl,
   otherwise utilizing bandwidth information will be challenging
   + preferably this bandwidth monitoring is not per NUMA node but rather
     slow and fast

Please let me know if you'd like to propose additional topics for
discussion, thank you!

[1]
https://lore.kernel.org/linux-mm/20260712-migrate-rmap-batch-v1-0-872a734431d1@amd.com/#t 

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

[SJ Park]

On Sat, 1 Aug 2026 20:40:35 -0700 (PDT) David Rientjes <rientjes@google.com> 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/20260525225208.1179-1-sj@kernel.org/
[3] https://lpc.events/event/19/contributions/2066/


Thanks,
SJ

[...]