Re: [RFC] __GFP_UNMAPPED and __GFP_PRIVATE follow up

[Brendan Jackman <jackmanb@google.com>]

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:
>> 
>> Yeah, I have had a similar thought before. In fact, I wonder if we could
>> have a pointer in there that effectively allows you to replace
>> NODE_DATA? I think that would be a more general mechanism to achieve
>> that `managed_node` thing?
>>
>
> Well, alloc_context already contains a nodemask.  I could see even
> pulling that argument into the struct if we seriously consider exporting
> alloc_context.
>
> 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.

>> My original motive for that was: if we could get the allocator to stop
>> [unconditionally] mutating global variables it would make it easier to
>> test.
>> 
>
> Can you expand on this a bit more?
> What globals are you referred to exactly?

IIRC it's just a few, the vast majority of the global mutable state is
ultimately downstream of NODE_DATA, plus there are some tuning knobs.

> There has been a desire on our side (Meta) to make mm/ more testable in
> general (for both performance and correctness) - include page_alloc.c
>
> But with everything so tightly coupled the best we can presently do is
> runtime testing of benchmarks and workloads.
>
> The same issue exists for things like LRU/MGLRU, where you can't really
> isolate a change because you get emergent properties.

Yeah basically just this; if you try to write a test that constructs
some specific condition to try and hit the nastiest possible fallback
case, you are racing against the real system. Ditto if you wanna check
your code against page_group_by_mobility_disabled=1, well you'd better
figure out a way to actually boot a whole system with that property.

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).

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.