Re: [PATCH] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof()

[Brendan Jackman]

On Thu Jun 18, 2026 at 6:56 AM UTC, Hao Ge wrote:
> Hi Brendan
>
>
> On 2026/6/17 23:29, Brendan Jackman wrote:
>> Currently the core allocator code is controlled by ALLOC_NOLOCK, but the
>> main entry point function is significantly different from the normal
>> __alloc_frozen_pages_nolock(), this is tiring when reading the code.
>>
>> Plumb the ALLOC_NOLOCK control one layer up in the call stack: create
>> an alloc_flags argument to __alloc_frozen_pages_nolock() (which is only
>> exposed to mm/) and then turn the nolock variant into a thin wrapper
>> that just sets that flag (as well as handling NUMA_NO_NODE, similar to
>> how some of the wrappers in gfp.h do).
>>
>> Rationale that this doesn't change anything:
>>
>> 1. Simple bits: A bunch of the nolock-specific handling is just moved to
>>     the new alloc_order_allowed(), alloc_trylock_allowed() and
>>     gfp_trylock.
>>
>> 2. __alloc_frozen_pages_noprof() has some extra logic that wasn't
>>     previously in the nolock variant:
>>
>>     a. Application of gfp_allowed_mask; this only affects early boot, and
>>        only flags that affect the slowpath get changed here.
>>
>>     b. Application of current_gfp_context() - also only affects the
>>        slowpath
>>
>> 3. The slowpath itself: this is now just explicitly skipped under
>>     !ALLOC_TRYLOCK.
>>
>> Ulterior motive: adding an alloc_flags arg to the allocator's
>> mm-internal entrypoint can later be used to do more allocation
>> customisation without needing to create new GFP flags.
>
>
> If so, I believe we could generalize this further.
>
> Under the current logic, |__alloc_pages_slowpath| cannot access the 
> alloc_flags
> passed down from upper-level callers.
> As I discussed in another thread, we can introduce a new alloc_flags to
> replace the |__GFP_NO_CODETAG| (|__GFP_NO_OBJ_EXT|) GFP flag.
> This newly added flag needs to be propagated along the entire call
> chain down to |prep_new_page|, which means |__alloc_pages_slowpath| also 
> has to
> handle this flag accordingly.
>
> I'm wondering if we could introduce a caller_alloc_flags field within 
> struct alloc_context
> to handle alloc_flags that need to persist throughout the entire page 
> allocation cycle, when such flags exist.
> I'm sure others will have more appropriate solutions.

Yeah totally, this is exactly how I imagined this evolving.