linux-kernel - Re: [RFC LPC2026 PATCH v2 00/11] Specific Purpose Memory NUMA Nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOi6=wTCPDM4xDJyzB1SdU6ChDch27eyTUtTAmajRNFhOFUN=A@mail.gmail.com>
Date: Thu, 11 Dec 2025 00:29:15 +0100
From: Yiannis Nikolakopoulos <yiannis.nikolakop@...il.com>
To: Gregory Price <gourry@...rry.net>
Cc: "David Hildenbrand (Red Hat)" <david@...nel.org>, linux-mm@...ck.org, kernel-team@...a.com, 
	linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org, 
	nvdimm@...ts.linux.dev, linux-fsdevel@...r.kernel.org, 
	cgroups@...r.kernel.org, dave@...olabs.net, jonathan.cameron@...wei.com, 
	dave.jiang@...el.com, alison.schofield@...el.com, vishal.l.verma@...el.com, 
	ira.weiny@...el.com, dan.j.williams@...el.com, longman@...hat.com, 
	akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com, 
	Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com, 
	mhocko@...e.com, osalvador@...e.de, ziy@...dia.com, matthew.brost@...el.com, 
	joshua.hahnjy@...il.com, rakie.kim@...com, byungchul@...com, 
	ying.huang@...ux.alibaba.com, apopple@...dia.com, mingo@...hat.com, 
	peterz@...radead.org, juri.lelli@...hat.com, vincent.guittot@...aro.org, 
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com, 
	mgorman@...e.de, vschneid@...hat.com, tj@...nel.org, hannes@...xchg.org, 
	mkoutny@...e.com, kees@...nel.org, muchun.song@...ux.dev, 
	roman.gushchin@...ux.dev, shakeel.butt@...ux.dev, rientjes@...gle.com, 
	jackmanb@...gle.com, cl@...two.org, harry.yoo@...cle.com, 
	axelrasmussen@...gle.com, yuanchu@...gle.com, weixugc@...gle.com, 
	zhengqi.arch@...edance.com, yosry.ahmed@...ux.dev, nphamcs@...il.com, 
	chengming.zhou@...ux.dev, fabio.m.de.francesco@...ux.intel.com, 
	rrichter@....com, ming.li@...omail.com, usamaarif642@...il.com, 
	brauner@...nel.org, oleg@...hat.com, namcao@...utronix.de, 
	escape@...ux.alibaba.com, dongjoo.seo1@...sung.com
Subject: Re: [RFC LPC2026 PATCH v2 00/11] Specific Purpose Memory NUMA Nodes

Just managed to go through the series and I think there are very good
ideas here. It seems to cover the isolation requirements that are
needed for the devices with inline compression.
As an RFC I can try to build something on top of it and test it more.

I hope we find the right abstractions for this to move forward.

On Tue, Nov 25, 2025 at 6:58 AM Gregory Price <gourry@...rry.net> wrote:
>
> On Mon, Nov 24, 2025 at 10:19:37AM +0100, David Hildenbrand (Red Hat) wrote:
> > [...]
> >
>
> Apologies in advance for the wall of text, both of your questions really
> do cut to the core of the series.  The first (SPM nodes) is basically a
> plumbing problem I haven't had time to address pre-LPC, the second (GFP)
> is actually a design decision that is definitely up in the air.
>
> So consider this a dump of everything I wouldn't have had time to cover
> in the LPC session.
>
> > > 3) Addition of MHP_SPM_NODE flag to instruct memory_hotplug.c that the
> > >     capacity being added should mark the node as an SPM Node.
> >
> > Sounds a bit like the wrong interface for configuring this. This smells like
> > a per-node setting that should be configured before hotplugging any memory.
> >
>
> Assuming you're specifically talking about the MHP portion of this.
>
> I agree, and I think the plumbing ultimately goes through acpi and
> kernel configs.  This was my shortest path to demonstrate a functional
> prototype by LPC.
>
> I think the most likely option simply reserving additional NUMA nodes for
> hotpluggable regions based on a Kconfig setting.
>
> I think the real setup process should look like follows:
>
> 1. At __init time, Linux reserves additional SPM nodes based on some
>    configuration (build? runtime? etc)
>
>    Essentially create:  nodes[N_SPM]
>
> 2. At SPM setup time, a driver registers an "Abstract Type" with
>    mm/memory_tiers.c  which maps SPM->Type.
>
>    This gives the core some management callback infrastructure without
>    polluting the core with device specific nonsense.
>
>    This also gives the driver a change to define things like SLIT
>    distances for those nodes, which otherwise won't exist.
>
> 3. At hotplug time, memory-hotplug.c should only have to flip a bit
>    in `mt_sysram_nodes` if NID is not in nodes[N_SPM].  That logic
>    is still there to ensure the base filtering works as intended.
>
>
> I haven't quite figured out how to plumb out nodes[N_SPM] as described
> above, but I did figure out how to demonstrate roughly the same effect
> through memory-hotplug.c - hopefully that much is clear.
>
> The problem with the above plan, is whether that "Makes sense" according
> to ACPI specs and friends.
>
> This operates in "Ambiguity Land", which is uncomfortable.
What you describe in a high level above makes sense. And while I agree
that ACPI seems like a good layer for this, it could take a while for
things to converge. At the same time different vendors might do things
differently (unsurprisingly I guess...). For example, it would not be
an absurd idea that the "specialness" of the device (e.g. compression)
appears as a vendor specific capability in CXL. So, it would make
sense to allow specific device drivers to set the respective node as
SPM (as I understood you suggest above, right?)

Finally, going back to the isolation, I'm curious to see if this
covers GPU use cases as Alistair brought up or HBMs in general. Maybe
there could be synergies with the HBM related talk in the device MC?

Best,
/Yiannis