Re: [RFC] __GFP_UNMAPPED and __GFP_PRIVATE follow up

[Gregory Price <gourry@gourry.net>]

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.

> 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?

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.

> My feeling from poking around in the code is that setting this up is
> actually quite a big job in page_alloc.c. But, I think it could be done
> in a way that leaves the code better instead of worse.
>

Yes, and being the literal bedrock for all of mm/ getting it wrong would
be catestrophic, so both a large job and high risk.

At the very least, using what exists (alloc_context) to extend to a new
interface for new users (unmapped, managed nodes, etc) while leaving what
is there until the new one becomes stable would be a good mitigation.

>
> There might be some annoying stuff like "turning these things that are
> currently function arguments into struct fields effectively causes a
> register spill and this code is hot enough for that to matter"? But that
> seems like a bridge to cross if we come to it, not something to
> premature-optimise over. (Do register spills matter in 2026 anyway?
> I think registers and the stack are kinda virtual?)
>

I'd be more worried about new stack allocations (alloc_context) and
populating it would lead to regressions than register spills, but it's
not worth thinking about untill there's data / it's testable.

(Another argument for making the core of this more testable)

>
> (Sorry this is such a vague thumbs up without really contributing
> anything but I'm just giving what I've got :D)
> 

I requested comments, i got comments :P Mission success.

~Gregory