[RFC] __GFP_UNMAPPED and __GFP_PRIVATE follow up

[RFC] __GFP_UNMAPPED and __GFP_PRIVATE follow up

[Gregory Price]

I'm sending this as a general follow up to the __GFP_UNMAPPED and
__GFP_PRIVATE proposals that were discussed at LSFMMBPF '26

__GFP_PRIVATE
https://lore.kernel.org/linux-mm/20260222084842.1824063-3-gourry@gourry.net/
__GFP_UNMAPPED
https://lore.kernel.org/linux-mm/20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com/

There is a general push to avoid new GFP flags, and there were common
questions about alloc_context.


I have an idea for that, but first, let me address something about
__GFP_PRIVATE.

For __GFP_PRIVATE there was a question about whether the global nodemask
interfaces could be fixed. I've taken a bit of time to look at this and
I'm again left saying: Not without completely reinventing the wheel.

In particular, there's nothing that prevents an N_MEMORY_PRIVATE node
from also being N_CPU or N_GENERIC_INTIATOR. 

In addition, there are a few hundred instances across the kernel of
nodemasks being cobbled together from node_states[] masks and stuff
like remap operations that may result in a private node finding its
way into a nodemask.

This kind of pattern isn't going away, and node_states have UAPI
implications associated with them :[.

The reality we really need to make the allocation request explicit
via some argument to the allocator if we want to re-use that code.


Yesterday I spitballed the addition of a new alloc interface:
https://lore.kernel.org/linux-mm/agS76pNPlPVLgpFA@gourry-fedora-PF4VCD3F/

I cannot speak for Brendan, however, in his cover letter he said:
https://lore.kernel.org/linux-mm/20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com/

  For now I still assume a GFP flag is the cleanest way to get that
  but in principle I'm not opposed to alloc_unmapped_pages() ...


His proposal looks a lot like ALLOC_CMA, in my opinion.

I'm wondering if we can solve both of these with an alloc_context
extension.  In fact, I'm wondering if some GFP flags should actually
be alloc flags anyway.

We have more flexibility with alloc_flags (for now) because they're only
defined in mm/internal.h.

Maybe we could modify alloc_flags to be a struct, and export that
without being tied to down to a 32/64-bit flag field - and mark certain
sets of alloc flags verboten (internally controlled / controlled by GFP
flags, and will either be ignored or cause a BUG()).

Then we could get something like:

    struct alloc_flags {
        /* 
	 * internal only: will be ignored, cleared, or cause BUG() if used,
	 * or should be applied via the appropriate __GFP flag.
	 */
        uint64_t wmark_min : 1;
        uint64_t wmark_low : 1;
        uint64_t wmark_high : 1;
	... etc ...
	/* 
	 * external context flags
	 * allows explicit access to certain resources
	 */
	uint64_t cma          : 1; /* allows access to CMA regions */
	uint64_t unmapped     : 1; /* return pages in unmapped state */
	uint64_t managed_node : 1; /* allows access to managed node */
	... etc ...
    };

    ___alloc_frozen_pages_noprof(..., struct alloc_context *ac) {
        ac->flags.wmark_low = 1;
	...
	prepare_alloc_pages(..., ac);
	ac->flags.nofrag = alloc_flags_nofragment(...)

	/* First allocation attempt */
        page = get_page_from_freelist(alloc_gfp, order, &ac);
	...
    }

    __alloc_frozen_pages_noprof(...) {
        struct alloc_context ac = {};

	___alloc_frozen_pages_noprof(..., ac);
    }

    __alloc_frozen_pages_context_noprof(..., struct alloc_flags *aflags) {
        struct alloc_context ac = {};
	
        /* Snapshot to prevent external changes */
	ac.flags = aflags ? *aflags : 0;

        sanitize_alloc_flags(&ac.flags); /* BUG() on insanity */
        ___alloc_frozen_pages_noprof(..., ac);
    }

For existing users, they can continue to use __GFP flags and existing
allocation interfaces.  For special context users, they can use the
context interface.

For __GFP_PRIVATE, this would look like modifying just a handful of
interfaces to include alloc_context or alloc_flags - e.g.:

   folio_alloc_mpol(gfp, order, pol, ilx, nid)
       ->
   folio_alloc_mpol(ac, order, pol_ilx, nid);

And a bit of logic to simply set:

   ac.flags.managed_node = 1;

This kind of pattern already exists with things like scan_control,
oom_control, etc - which carry gfp masks around.  Maybe those things
should just carry the full alloc_context around (w/ gfp and flags).

~Gregory

Re: [RFC] __GFP_UNMAPPED and __GFP_PRIVATE follow up

[Brendan Jackman]

On Thu May 14, 2026 at 5:42 PM UTC, Gregory Price wrote:
...
> Maybe we could modify alloc_flags to be a struct, and export that
> without being tied to down to a 32/64-bit flag field - and mark certain
> sets of alloc flags verboten (internally controlled / controlled by GFP
> flags, and will either be ignored or cause a BUG()).
>
> Then we could get something like:
>
>     struct alloc_flags {
>         /* 
> 	 * internal only: will be ignored, cleared, or cause BUG() if used,
> 	 * or should be applied via the appropriate __GFP flag.
> 	 */
>         uint64_t wmark_min : 1;
>         uint64_t wmark_low : 1;
>         uint64_t wmark_high : 1;
> 	... etc ...
> 	/* 
> 	 * external context flags
> 	 * allows explicit access to certain resources
> 	 */
> 	uint64_t cma          : 1; /* allows access to CMA regions */
> 	uint64_t unmapped     : 1; /* return pages in unmapped state */
> 	uint64_t managed_node : 1; /* allows access to managed node */
> 	... etc ...
>     };
>
>     ___alloc_frozen_pages_noprof(..., struct alloc_context *ac) {
>         ac->flags.wmark_low = 1;
> 	...
> 	prepare_alloc_pages(..., ac);
> 	ac->flags.nofrag = alloc_flags_nofragment(...)
>
> 	/* First allocation attempt */
>         page = get_page_from_freelist(alloc_gfp, order, &ac);
> 	...
>     }
>
>     __alloc_frozen_pages_noprof(...) {
>         struct alloc_context ac = {};
>
> 	___alloc_frozen_pages_noprof(..., ac);
>     }
>
>     __alloc_frozen_pages_context_noprof(..., struct alloc_flags *aflags) {
>         struct alloc_context ac = {};
> 	
>         /* Snapshot to prevent external changes */
> 	ac.flags = aflags ? *aflags : 0;
>
>         sanitize_alloc_flags(&ac.flags); /* BUG() on insanity */
>         ___alloc_frozen_pages_noprof(..., ac);
>     }

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?

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.

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.

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

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