[Linux Memory Hotness and Promotion] Notes from August 28, 2025

[Linux Memory Hotness and Promotion] Notes from August 28, 2025

[David Rientjes]

Hi everybody,

Here are the notes from the last Linux Memory Hotness and Promotion call
that happened on Thursday, August 28.  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-----
I provided the updates from Bharata: he moved the ratelimiting and dynamic
threshold logic from the existing NUMAB=2 to kpromoted, although this
needed to be tested.  Hopeful this would be ready to share by next
meeting.  He further modified NUMAB=2 to just do scanning and hint faults
and then feed the access information into the single source of truth.

He also had updated that IBS, NUMAB=2, and klruscand were now the three
sources of page hotness information available.  Bharata was also planning
for some optimizations to share in two weeks time.

----->o-----
We discussed Raghu's slowtier page promotion based on PTE Accessed bit
scanning.  He said it was still an independent patch series.  Next, he
plans on implementing fallback target nodes for migration.  He's also
planning on a rename to something like kcollector.  After that, the idea
is to integrate into Bharata's patch series.  He suggested a possible API
extension to support things like promoting memory on the second access
(NUMAB).  In the next two weeks, he planned this integration work with
Bharata's series.

Raghu asked for feedback on the current series of patches to be provided
upstream.

Jonathan Cameron talked about IBS equivalents for other architectures
such as ARM[1].  This would be another page hotness source that could be
integrated in the future.

----->o-----
We discussed klruscand from Kinsey Ho.  Kinsey had posted another revision
of that patch series upstream[2] but not yet integrating with Bharata's
series given that RFC had not been posted yesterday.  Asked about the
scope of that series, Kinsey was only planning clean-ups at the time.

Now that the latest Bharata series has been posted, it will be possible to
integrate klruscand further into that.  It could be posted either as one
big integrated patch series or standalone, no strong opinions.

Wei Xu asked if Raghu had ever tested with MGLRU enabled, i.e. handling
the PTE A set and clear.  Raghu said that he is dependent on the idle page
flag.  Raghu suggested experimenting with both approaches and then
deciding the right path forward.  He had been enabling MGLRU but not yet
integrating with his approach.

----->o-----
We shifted to discussing non-temporal stores.  Yiannis noted that he had
some RFC patches for this that he sent over to attendees afterwards.
Yiannis described this as internal patches being used over the past couple
months although it is not yet optimal and doesn't have the right
abstraction level.

Wei Xu shared previous experiences with non-temporal stores and bypassing
caches, especially for demotion paths.  One of the challenges is to tell
the page copy code that we are doing demotions and the lack of
migrate_pages() to have a full end-to-end context that this migration is
for things like demotion.

Raghu said there were additional optimizations that would be available
beyond just non-temporal stores here if we had this enlightenment.

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

Topics for the next meeting:

 - updates on testing for the NUMAB=2 move to kpromoted, including
   ratelimiting and dynamic threshold logic
 - update on integration of PTE Accessed bit scanning with Bharata's
   series
 - update for integration of klruscand going forward and next steps beyond
   cleanups
 - discussion on non-temporal stores and how to enlighten the promotion or
   demotion logic on top of it
   + discuss testing and benchmarking Yiannis's RFC patch
 - enlightening migrate_pages() for hardware assists and how this work
   will be charged to userspace
 - discuss proactive demotion interface as an extension to memory.reclaim
 - discuss overall testing and benchmarking methodology for various
   approaches as we go along

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

[1] https://gitee.com/openeuler/kernel/pulls/16342
[2] https://marc.info/?l=linux-mm&m=175754854525170&w=2