Message-ID: <h7vt26ek4wzrls6twsveinxz7aarwqtkhydbgvihsm7xzsjiuz@yk2dltuf2eoh>
Date: Tue, 25 Nov 2025 14:09:39 +0000
From: Kiryl Shutsemau <kirill@...temov.name>
To: Gregory Price <gourry@...rry.net>
Cc: 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, david@...hat.com, 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

On Wed, Nov 12, 2025 at 02:29:16PM -0500, Gregory Price wrote:
> With this set, we aim to enable allocation of "special purpose memory"
> with the page allocator (mm/page_alloc.c) without exposing the same
> memory as "System RAM".  Unless a non-userland component, and does so
> with the GFP_SPM_NODE flag, memory on these nodes cannot be allocated.

How special is "special purpose memory"? If the only difference is a
latency/bandwidth discrepancy compared to "System RAM", I don't believe
it deserves this designation.

I am not in favor of the new GFP flag approach. To me, this indicates
that our infrastructure surrounding nodemasks is lacking. I believe we
would benefit more by improving it rather than simply adding a GFP flag
on top.

While I am not an expert in NUMA, it appears that the approach with
default and opt-in NUMA nodes could be generally useful. Like,
introduce a system-wide default NUMA nodemask that is a subset of all
possible nodes. This way, users can request the "special" nodes by using
a wider mask than the default.

cpusets should allow to set both default and possible masks in a
hierarchical manner where a child's default/possible mask cannot be
wider than the parent's possible mask and default is not wider that
own possible.

> Userspace-driven allocations are restricted by the sysram_nodes mask,
> nothing in userspace can explicitly request memory from SPM nodes.
> 
> Instead, the intent is to create new components which understand memory
> features and register those nodes with those components. This abstracts
> the hardware complexity away from userland while also not requiring new
> memory innovations to carry entirely new allocators.

I don't see how it is a positive. It seems to be negative side-effect of
GFP being a leaky abstraction.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Powered by blists - more mailing lists