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
