Re: revisiting alloc_pages_bulks semantics?

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 5/27/26 09:18, Christoph Hellwig wrote:
> Hi all,
> 
> I've been looking into using alloc_pages_bulks in a few places lately,
> and have run into issues with the API.  Here is my suggestions for how
> to make this more useful, although only some of them are something
> I'd feel comfortable to do myself:
> 
> 1) early fail semantics
> 
> alloc_pages_bulks can do partial allocations for some reasons, and
> users usually have a fallback by either looping and calling it again
> or falling back to single page allocations.  This sucks!  Why can't
> we get our usual try as hard as you can semantics, requiring
> GFP_NORETRY or similar to relax it?

If we do that, do we keep the possibility of partial success, i.e. return
how many were allocated? Seems wasteful to suceed N-1 and then throw all
away, if the caller can use a fallback only for the last one.
Do some callers need all-or-nothing semantics? Should a flag indicate which
one to use?

> 2) pre-zeroed page array 
> 
> There is one single user (svc_fill_pages in sunrpc) that relies on it.
> For everyone else it creates extra burden and is very error prone
> (speaking from experience).

Sounds good to me. Will sunrpc be easy to convert, or should it be another
flag to opt-in to the current behavior, that it would use?

> 3) page instead of folio
> 
> We're allocating folios, so we should have a folio API.

Hm, folios initially started as "base or compound page" but then the
semantics shifted and now they are also rmappable. See how
folio_alloc_noprof() does page_rmappable_folio(). The differences might grow
further with memdesc conversion I think.
So do all the callers actually want folios? If not, we could have both
alloc_pages_bulk() and folio_alloc_bulk()?

> 4) > order 0 support
> 
> The bulk allocator is limited to order 0 which limits it's usefulness
> these days.  It would be really helpful to do bulk allocations for
> the pagecache or bounce buffering.

Fine, with implications for the comment for 1)