linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Davidlohr Bueso <dave@stgolabs.net>, Fan Ni <nifan.cxl@gmail.com>,
	 Frank van der Linden <fvdl@google.com>,
	Gregory Price <gourry@gourry.net>,
	 Jonathan Cameron <jic23@kernel.org>,
	Joshua Hahn <joshua.hahnjy@gmail.com>,
	 Raghavendra K T <rkodsara@amd.com>,
	 "Rao, Bharata Bhasker" <bharata@amd.com>,
	SeongJae Park <sj@kernel.org>,  Wei Xu <weixugc@google.com>,
	Xuezheng Chu <xuezhengchu@huawei.com>,
	 Yiannis Nikolakopoulos <yiannis@zptcorp.com>,
	Zi Yan <ziy@nvidia.com>
Cc: linux-mm@kvack.org
Subject: [Linux Memory Hotness and Promotion] Notes from July 16, 2026
Date: Sat, 18 Jul 2026 15:19:58 -0700 (PDT)	[thread overview]
Message-ID: <6e07d152-d746-ad9d-9426-bf51647338d0@google.com> (raw)

Hi everybody,

Here are the notes from the last Linux Memory Hotness and Promotion call
that happened on Thursday, July 16.  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 offline that he'll work on getting his non-temporal stores 
patch series on the upstream mailing list in the next couple of weeks.  
Huan also noted that would attend the next meeting to discuss the progress 
on memory error handling for NT stores.  Wei noted that ARM memcpy should 
not need this support, but Jonathan suggested that there actually were 
specific instructions for this on ARM although all implementations may not 
actually use it[1].

----->o-----
We discussed LPC in Prague for October 5-7.  The list of microconferences 
was available on the website[2], there are both "device memory" 
conferences as well as general MM.  Shivank noted that he and Zi were 
collaborating on page migration offloads as well as rmap walk batching.  
He is also proposing simplification of migrate_pages() and the ABIs around 
that, including context information.  I was concerned that we'd be delayed 
until LPC to make forward progress on this, Shivank was actively working 
on this.

Joshua noted that he had discussed tier-aware memcg limits at LSF/MM/BPF 
so probably won't have a ton of new content for LPC.  Jonathan suggested 
we may want to have a BOF simply for memory hotness and promotion work, 
similar to what we talk about in this call.

----->o-----
Bharata updated on the status of his patch series.  He now is working on 
finalizing v8 of the series that includes bug fixes.  There are some 
behavioral changes that support NUMAB better and more closely support that 
implementation.  He is collecting numbers on the patch series and, if 
there are no issues, then he will send the series upstream next week.  He 
is also working on supporting for the second instance of IBS that is 
specific to memory access information.  This will also be included in the 
v8 series to be sent upstream.

----->o-----
Shviank updated on his series of changes for migrate_pages(), now at v6 
upstream.  He is continuing to post as an RFC for now and has addressed 
Sashiko review and feedback from David Hildenbrand.

Teja Vojjala had been testing on Zen3 hardware for PTDMA and has been able 
to reproduce Shivank's numbers.  He had observed many context switches, 
however, and suggested we should be able to optimize this.  He asked 
Shivank if there has been testing done on SDXI.  Shivank confirmed this 
and said that he can provide a patch to Teja for testing.  I asked how the 
feedback should be provided, Shivank suggested feedback on the upstream 
mailing list would show more interest in it and we should likely pivot 
toward the SDXI use case.

I suggested to Teja that we should be able to product a list of blockers 
that are preventing us from productizing this support so we can iterate 
through them and get on a path to using these in production.  Teja asked 
if PTDMA is a legitimate use case and it is, but Shivank suggested 
focusing on future platforms with SDXI.

----->o-----
Joshua sent out his latest series of tier-aware memcg limits to me and he 
wanted to do more testing before sending it out to the upstream list 
again.  I noted that we will try to find two engineers to look over the 
patch series and provide feedback on the API and overall support, as well 
as any potential gaps that we see based on prodution use cases.  I'm 
especially interested in any blockers that would prevent us from 
productionizing this.
 
----->o-----
Gregory noted he was investing time in looking at how to optimize 
demotions and possible LRU inversions.  Once a lower tier becomes full and 
there's memory pressure on the system, we start demoting to an even lower 
tier directly.  He's been looking into better LRU ordering.  He is 
continuing to work on this and will send it out to this group when ready.

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

Topics for the next meeting:

 - update on Yiannis's RFC for non-temporal stores enlightenment in
   migrate_pages()
   + update on Huan's support for memory error handling for NT stores
 - v8 of Bharata's patch series, including new IBS memory profiler
   support and benchmark numbers that were collected
 - v6 of Shivank's series for enlightening migrate_pages() for hardware
   assists and how this work will be charged to userspace, including for
   memory compaction, and separating the first patches out into a non-RFC
   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://developer.arm.com/documentation/ddi0602/2021-09/Base-Instructions/CPYPWN--CPYMWN--CPYEWN--Memory-Copy--writes-non-temporal- 
[2] 
https://lpc.events/event/20/contributions/?config=c513701b-9743-4b41-914c-c1f29ee2307f 


                 reply	other threads:[~2026-07-18 22:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6e07d152-d746-ad9d-9426-bf51647338d0@google.com \
    --to=rientjes@google.com \
    --cc=bharata@amd.com \
    --cc=dave@stgolabs.net \
    --cc=fvdl@google.com \
    --cc=gourry@gourry.net \
    --cc=jic23@kernel.org \
    --cc=joshua.hahnjy@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=nifan.cxl@gmail.com \
    --cc=rkodsara@amd.com \
    --cc=sj@kernel.org \
    --cc=weixugc@google.com \
    --cc=xuezhengchu@huawei.com \
    --cc=yiannis@zptcorp.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).