Re: [RFC PATCH 0/6] mm: pass alloc_flags through folio, filemap, and bulk allocators

["David Hildenbrand (Arm)" <david@kernel.org>]

On 10/8/26 11:10, Gregory Price wrote:
> On Wed, Sep 23, 2026 at 05:10:34PM -0400, Gregory Price wrote:
>> This six-patch series first separates allocator behavior flags from
>> the bulk allocator fast-path flags and shares their validation and
>> preparation. It then passes alloc_flags through the MM-internal folio,
>> NUMA policy, filemap, and bulk helpers.
> 
> I had various discussions this week regarding ALLOC_ZONELIST_PRIVATE and
> ALLOC_UNMAPPED, and whether adding alloc_flags to the APIs is a good/bad
> idea and what the alternatives are.  I'd like to summarize the notes
> here and try to find a way forward.
> 
> recommendations that were made:
> 
> 1) re-use unused GFP flags
>    #define __GFP_X  __GFP_DMA
>    or simply delete/replace __GFP_DMA

If so, I think the latter,

> 
>    There presently are no truly unused GFP flags, though there may be
>    some users who can be shuffled around if we are willing to add
>    functions.

I once had patches to convert __GFP_SKIP_ZERO and __GFP_SKIP_KASAN to alloc
flags instead. Nobody outside core-mm should be setting these, ever.

> 
> 2) alias 2+ incompatible GFP flags to make a new one
>    #define GFP_A (__GFP_NORETRY | __GFP_RETRY_MAYFAIL)
>    #define GFP_B (__GFP_NORETRY | __GFP_NOFAIL)
>    #define GFP_C (__GFP_NOFAIL | __GFP_RETRY_MAYFAIL)
>    #define GFP_X (__GFP_DMA | __GFP_DMA32)
>    #define GFP_Y (__GFP_DMA | __GFP_HIGHMEM)
>    #define GFP_Z (__GFP_DMA32 | __GFP_HIGHMEM)
> 
>    These are all nonsensical combinations.
> 
>    Downside: We should probably just forbid these, otherwise the function
>    contract just ends up being confusing - i.e. (__GFP_DMA | __GFP_DMA32)
>    should just warn / return NULL.
> 

Not a fan of this.

> 
> 3) expose alloc_flags as mm-internal only flags (this series)
>    in addition - convert some GFP flags to ALLOC flags
> 
>    In 99% of callers they would simply add ALLOC_DEFAULT (0).
> 
>    The upside - it seems like there are 2-3 GFP flags that may be
>    good candidates for conversion to alloc flags:
>      __GFP_WRITE
>      __GFP_ZEROTAGS
>      __GFP_SKIP_ZERO

Yes, as mentioned above that was my plan.

> 
>    And the zone/zonelist selectors seem like candidates to free up GFP
>    flags by turning them into internal-only flags and giving drivers
>    some kind of explicit API, e.g.:
>      __GFP_DMA/__GFP_DMA32 -> dma_alloc(...) -> intenal ALLOC_DMA|32
> 
>    I considered whether __GFP_THISNODE should actually be broken up,
>    as it actually means two things (don't oom, use thisnode zonelist)
>    Something like:
>      ALLOC_NO_OOM
>      ALLOC_THISNODE_ZONELIST  (or keep __GFP_THISNODE)
> 
>    The downside is yet another flag interface in the page allocator.
>    Note: This is basically 1/2 way done, this series finishes it.

I do agree that two sets of flags is suboptimal, but likely more flexible. I
guess an alloc_flags only interface is not easily possible ...

I do wonder whether it should be:

	typedef int __bitwise alloc_flags_t;

instead of "unsigned int alloc_flags".

... while at it

-- 
Cheers,

David