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

[Gregory Price <gourry@gourry.net>]

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

   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.

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.


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

   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.


4) simply add functions to the page allocator

   folio_alloc_private(...) {
     alloc_flags |= ALLOC_ZONELIST_PRIVATE;
   }

   This has the downsize of requiring page allocation callers to know
   more than page/folio allocator functions if they want a particular
   type of page (unmapped, private, etc) and increases the surface of
   the page allocator.


Would like to find a path foward.  I lean towards GFP -> ALLOC flag
conversion and making alloc_flags internal-only.

~Gregory