Re: [PATCH 1/2] mm: page_alloc: do not give all non-blocking requests reserve access

[Vlastimil Babka (SUSE)]

On 9/21/26 5:58 PM, Johannes Weiner wrote:
> On Mon, Sep 21, 2026 at 03:54:32PM +0100, Matthew Wilcox wrote:
>> On Mon, Sep 21, 2026 at 10:38:18AM -0400, Johannes Weiner wrote:
>>> +++ b/mm/page_alloc.c
>>> @@ -3246,7 +3246,9 @@ struct page *rmqueue_buddy(struct zone *preferred_zone, struct zone *zone,
>>>  			 * reserves as failing now is worse than failing a
>>>  			 * high-order atomic allocation in the future.
>>>  			 */
>>> -			if (!page && (alloc_flags & (ALLOC_OOM|ALLOC_NON_BLOCK)))
>>> +			if (!page &&
>>> +			    ((alloc_flags & ALLOC_OOM) ||
>>> +			     (alloc_flags & ALLOC_MASK_ATOMIC) == ALLOC_MASK_ATOMIC))
>>>  				page = __rmqueue_smallest(zone, order, MIGRATE_HIGHATOMIC);
>>
>> Would this be slightly neater?
>>
>> static inline bool may_access_reserves(unsigned int alloc_flags)
>> {
>> 	if (alloc_flags & ALLOC_OOM)
>> 		return true;
>> 	if (alloc_flags & (ALLOC_NON_BLOCK | ALLOC_MIN_RESERVE)) ==
>> 	    (ALLOC_NON_BLOCK | ALLOC_MIN_RESERVE)
>> 		return true;
>> 	return false;
>> }

I think it should be named e.g. may_access_highatomic_reserves() as
may_access_reserves() is rather generic and would seem to imply an
ALLOC_RESERVES match (see 2/2).

> 
> I tend to be hesitant with single-use abstractions, but no objection
> if people think this is better.

True but single-use ALLOC_MASK_ATOMIC is also not that great, and the
usage makes the code hard to decipher. And see my reply to 2/2.