Re: [RFC] __GFP_UNMAPPED and __GFP_PRIVATE follow up

[Gregory Price <gourry@gourry.net>]

On Fri, May 15, 2026 at 05:09:21PM +0000, Brendan Jackman wrote:
> On Fri May 15, 2026 at 3:48 PM UTC, Gregory Price wrote:
> > On Fri, May 15, 2026 at 09:43:02AM +0000, Brendan Jackman wrote:
> >
> > I'll have to think about the NODE_DATA replacement.  I don't know if
> > that's really feasible consider that this structure is used statically
> > all over the kernel for runtime node-data lookups from pages/folios.
> 
> Oh yeah I wasn't thinking of replacing it completely, more that the
> global NODE_DATA is the "default" node data (and the pointer field being
> NULL would probably mean to use that), but then private node datas could
> also exist.
>

More accurately - any node in node_state[N_MEMORY].

Any node not in node_state[N_MEMORY] and is essentially invisible to
page_alloc.c by nature of not being in any fallback lists.

In my series I don't add the private node to N_MEMORY, instead add
N_MEMORY_PRIVATE and never add them to the fallback list of normal
nodes, that makes them functionally invisible unless you call
alloc_pages_node() with that node id.

If you stop there, then alloc_pages_node(private_nid, ...) works
exactly the same as it did before (which is actually an issue in my
case, as you still have to contend with other nodemasks containing the
node id still).

So if you wanted to go off testing the page allocator, you could do it
with a private node.  Since otherwise the node gets exempted from the
rest of mm/, you'd just need to make sure to use __GFP_THISNODE so your
allocations fail w/o calling oom infrastructure and handle those
conditions accoridingly.

> 
> I spent a few days trying to solve this in the way that VMA and xarray
> etc have, i.e. by making the page allocator a library and then testing
> it from userspace. I think that would work but it needs much more than a
> few days to make it happen (admittedly, I had tried to do this with AI
> at the time and it failed miserably. Maybe with today's models it would
> work, which could massively accelerate the grunt work of e.g. splitting
> stuff into new files).
> 

I doubt you could get enough parity in userspace to make this a useful
exercise.  All the per-cpu interactions turn into per-thread
interactions, and you'd end up deleting most of what makes page_alloc.c
useful (all the external interactions - reclaim, compaction, oom, etc).

Plus there's cgroup/cpuset and accounting interactions that are
non-trivial.

The more I think about this, the less I think it's a tractable problem
ending in a mergable series.

> But anyway, if you could carve out a distinct node data etc you could just
> write KUnit tests that operate on a completely isolated "instance" of
> the allocator, even though it still runs in a real kernel.

I'm fairly certain private nodes basically already do this - with the
exception of certain global counters (vm stats), and certain global
settings (like you describe above).

~Gregory