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

[JP Kobryn <jp.kobryn@linux.dev>]

On 6/17/26 6:02 AM, Vlastimil Babka (SUSE) wrote:
> On 6/16/26 21:14, 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 above order-0 and up to the
>> costly order to use existing MIGRATE_HIGHATOMIC reserves on the buddy
>> fastpath without granting permission to grow these reserves. Add
>> ALLOC_HIGHATOMIC_RESERVE for allocations that may both access
>> MIGRATE_HIGHATOMIC and grow the reserves. Change the semantics of
>> ALLOC_HIGHATOMIC so that it may only access the reserves.
>>
>> 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, comparable runs consumed available
>> blocks for 96-100% of eligible order-1 atomic allocations reaching the
>> buddy path, 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.
> 
> Great.
> 
>> Signed-off-by: JP Kobryn <jp.kobryn@linux.dev>
> 
> LGTM, I have just one style suggestion. If you agree and apply it, feel free
> to add:
> 
> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>

Thanks for the quick review.

> 
> ... and (unless other reviews raise something) send v2 rebased to 7.2-rc1
> once it's released. Thanks!
> 
>> ---
>>  mm/internal.h   |  4 +++-
>>  mm/page_alloc.c | 34 +++++++++++++++++++++++++++-------
>>  2 files changed, 30 insertions(+), 8 deletions(-)
>>
[...]
> 
> And only here add both ALLOC_HIGHATOMIC and ALLOC_HIGHATOMIC_RESERVE.
> I.e. ALLOC_HIGHATOMIC_RESERVE would not be a superset of ALLOC_HIGHATOMIC,
> but access to reserves and ability to grow them would be decoupled. The
> comments on the flags actually suggest that's the case.

I like this idea and will decouple in v2.