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).