Message-ID: <de15aca2-a27c-4a9b-b2bf-3f132990cd98@kernel.org>
Date: Mon, 24 Nov 2025 10:19:37 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Gregory Price <gourry@...rry.net>, linux-mm@...ck.org
Cc: 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

[...]

> 2) The addition of `cpuset.mems.sysram` which restricts allocations to
>     `mt_sysram_nodes` unless GFP_SPM_NODE is used.
> 
>     SPM Nodes are still allowed in cpuset.mems.allowed and effective.
> 
>     This is done to allow separate control over sysram and SPM node sets
>     by cgroups while maintaining the existing hierarchical rules.
> 
>     current cpuset configuration
>     cpuset.mems_allowed
>      |.mems_effective         < (mems_allowed ∩ parent.mems_effective)
>      |->tasks.mems_allowed    < cpuset.mems_effective
> 
>     new cpuset configuration
>     cpuset.mems_allowed
>      |.mems_effective         < (mems_allowed ∩ parent.mems_effective)
>      |.sysram_nodes           < (mems_effective ∩ default_sys_nodemask)
>      |->task.sysram_nodes     < cpuset.sysram_nodes
> 
>     This means mems_allowed still restricts all node usage in any given
>     task context, which is the existing behavior.
> 
> 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.

> 
>     A node is either SysRAM or SPM - never both.  Attempting to add
>     incompatible memory to a node results in hotplug failure.
> 
>     DAX and CXL are made aware of the bit and have `spm_node` bits added
>     to their relevant subsystems.
> 
> 4) Adding GFP_SPM_NODE - which allows page_alloc.c to request memory
>     from the provided node or nodemask.  It changes the behavior of
>     the cpuset mems_allowed and mt_node_allowed() checks.

I wonder why that is required. Couldn't we disallow allocation from one 
of these special nodes as default, and only allow it if someone 
explicitly passes in the node for allocation?

What's the problem with that?

-- 
Cheers

David

Powered by blists - more mailing lists