Re: [PATCH v3] mm/page_alloc: use existing highatomic reserves on the buddy fastpath

[Shakeel Butt]

On Mon, Jun 22, 2026 at 05:46:00PM -0700, JP Kobryn wrote:
> ALLOC_HIGHATOMIC currently provides both access to MIGRATE_HIGHATOMIC free
> pages and permission to create new highatomic pageblock reserves. This
> makes it unsuitable for the fastpath.
> 
> However, the fastpath can reach rmqueue_buddy() while MIGRATE_HIGHATOMIC
> reserves have free pages available. In this situation, the allocation can
> fall back to other migratetypes without trying those reserves first.
> 
> Allow high-priority non-blocking allocations to use existing
> MIGRATE_HIGHATOMIC reserves on the buddy fastpath without growing them.
> First tighten the criteria for reserving pageblocks so that growth may only
> occur in the slowpath. Then allow fastpath usage by enabling
> ALLOC_HIGHATOMIC when the GFP mask describes a non-blocking high-priority
> allocation. This logic has been factored out from gfp_to_alloc_flags() to a
> new function gfp_to_alloc_flags_nonblocking().
> 
> A UDP receive workload was run with free MIGRATE_HIGHATOMIC pageblocks
> available in the target zone. Before this patch, the workload did not
> consume these blocks. With this patch, eligible order-1 allocations
> reaching the buddy path consumed existing MIGRATE_HIGHATOMIC pageblocks,
> with no highatomic misses observed. The workload did not grow highatomic
> reserves and NAPI page-frag allocations remained healthy with no failures
> or order-0 fallbacks.
> 
> Signed-off-by: JP Kobryn <jp.kobryn@xxxxxxxxx>

This is awesome.

Reviewed-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>