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

[Gregory Price <gourry@gourry.net>]

On Thu, Oct 15, 2026 at 12:02:06PM +0200, Vlastimil Babka (SUSE) wrote:
> On 10/10/26 01:28, Gregory Price wrote:
> > On Fri, Oct 09, 2026 at 10:55:05PM +0200, David Hildenbrand (Arm) wrote:
> >> 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 ...
> 
> Agree with the alloc_flags option of all the other options.
> 
> >> I do wonder whether it should be:
> >> 
> >> 	typedef int __bitwise alloc_flags_t;
> >> 
> >> instead of "unsigned int alloc_flags".
> >> 
> >> ... while at it
> 
> Can't hurt, but given how it's internal only it didn't seem that urgent as
> for gfp.
> 
> > Does it make sense to leave alloc_flags to internal-only state
> > and just implement a new flag field?
> > 
> > gfp_t       -> describe the page (fully public)
> > req_t       -> describe the allocator behavior (mm-internal only)
> > alloc_flags -> internal allocator state only
> 
> Maybe in that case the remaining alloc_flags should just become 1-bit fields
> directly in struct alloc_context so we don't manage 3 separate bitwise
> types. Or more bits in case of ALLOC_WMARK?
> 

I think that would be much less disruptive.

> Depends on how much work this would be (and if you want to do it) and how
> the result would like.

I took a short look at converting __GFP_SKIP_ZERO and the change has
bigger than i thought it would be.

Yosry recently said ALLOC_UNMAPPED was being put on hold, and for my
base private node series it seems I will only need to extend folio_alloc
with with alloc flags - so i will probably try to split these efforts up
and carry the minimal folio_alloc patch separately.

Otherwise i'll look at whether we can move some alloc_flags into
alloc_context bit fields somewhat cleanly as a first step.

~Gregory