On Thu, May 21, 2026 at 04:23:28PM +1000, Balbir Singh wrote: > On Sun, Feb 22, 2026 at 03:48:15AM -0500, Gregory Price wrote: > > Topic type: MM > > > > Presenter: Gregory Price <[email protected]> > > > > This series introduces N_MEMORY_PRIVATE, a NUMA node state for memory > > managed by the buddy allocator but excluded from normal allocations. > > > > I present it with an end-to-end Compressed RAM service (mm/cram.c) > > that would otherwise not be possible (or would be considerably more > > difficult, be device-specific, and add to the ZONE_DEVICE boondoggle). > > > > Do we have updates/notes from the meeting? >
I have been on leave since LSF, but I do have some notes posted: https://lore.kernel.org/linux-mm/af9i7dkNvGGxPHzu@gourry-fedora-PF4VCD3F/ https://lore.kernel.org/linux-mm/agYJcRgOHho8upVv@gourry-fedora-PF4VCD3F/ I will be trying to post an updated set stripped down without the GFP flag as a first pass w/o RFC tags and no UAPI implications so that device folks can play with this upstream. I'm debating on whether to include OPS_MEMPOLICY in the initial version if only because it's not intuitive how it interacts with pagecache. That needs more time to bake. > > > > page = alloc_pages_node(nid, __GFP_PRIVATE, 0); > > Do we want to provide kernel level control over allocation of private > pages, I assumed that only user space applications? I would assume > node affinity would be the way to do so, unless we have multiple > alloc_pages_node() is the kernel interface > > > > /* Ok but I want to do something useful with it */ > > static const struct node_private_ops ops = { > > .migrate_to = my_migrate_to, > > .folio_migrate = my_folio_migrate, > > .flags = NP_OPS_MIGRATION | NP_OPS_MEMPOLICY, > > }; > > node_private_set_ops(nid, &ops); > > > > Could you explain this further? Why does OPS_MIGRATION > and OPS_MEMPOLICY needs to be set explictly? > Both of these have been removed from the upcoming version, but in this RFC version i was testing OPS_MIGRATION as an explicit flag that meant "migrate.c can touch the folios" while OPS_MEMPOLICY meant "mempolicy.c can touch the folios". As it turns out, OPS_MIGRATION is not a useful filter, as it doesn't actually filter anything (anything using OPS_MIGRATION would also need its own filter flag, so better to just drop it and do per-server opt-ins). ~Gregory
