Re: revisiting alloc_pages_bulks semantics?

[Zi Yan]

On 27 May 2026, at 15: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:

I have some questions below to get more details on your needs.

>
> 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?

IIUC, current alloc_pages_bulks() tries to get free pages without doing
compaction or reclaim unless none can be allocated. Does your “usual try”
mean possible invocation of compaction and/or reclaim for every page
allocation? I guess it also relates to the order > 0 bulk allocation
below? My gut feeling is that if one “usual try” fails, the following
“usual try” might not work. So making alloc_pages_bulks() do heavy
allocation might not buy you much.

But can you elaborate on why looping alloc_pages_bulks() does not work
well? That is essentially triggering compaction/reclaim repeatedly
like your proposed “usual try” idea.

>
> 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).

No comment for this one.

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

Sounds reasonable to me.

>
> 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.

Sounds reasonable to me, but when under memory pressure, I wonder
how many > order 0 folios you can get in the end. And that might
cause a storm of compaction and/or reclaim if combined with Idea 1.
For > order 0 bulk allocations, are you thinking about 1)
a try and bail-out early model or 2) a keep-trying model?
For the latter, I wonder how large the allocation latency can be
and if that is tolerable or even makes sense, since for THP
allocations, we have seen >30s allocation latency when under
memory pressure. Is waiting minutes for bulk > order 0 allocation
making sense in your use cases?

Thanks.


Best Regards,
Yan, Zi