Re: order-0 page alloc failures during interrupt context on v6.6.43

[Vlastimil Babka <vbabka@suse.cz>]

On 8/30/24 17:43, Matt Fleming wrote:
> On Thu, Aug 29, 2024 at 4:48 PM Vlastimil Babka <vbabka@suse.cz> wrote:
>> AFAICS:
>>
>> - __zone_watermark_unusable_free() for ALLOC_RESERVES (which includes
>> ALLOC_NON_BLOCK which GFP_ATOMIC allocations have) does not subtract the
>> reserve_highatomic, so the allocations pass the watermarks
>> - but in rmqueue_buddy() only ALLOC_OOM is able to fallback into highatomic
>> - unreserve_highatomic_pageblock() is only called from reclaim and there's
>> no reclaim for GFP_ATOMIC
>>
>> (also worth checking if kswapd even does anything if free > high, but it's
>> all highatomic, maybe not? so it can't help us here)
> 
> As far as I can tell we'll wake kswapd but like you said because free
>> high it thinks the pgdat is balanced.

Hm wonder if we should change that and kswapd should count free without
highatomic reserve.

> How is the system supposed to recover in this situation? Wait for a
> non-atomic alloc to fail and enter direct reclaim?

That's probably how it recovers but it's not how it's supposed to recover :)
Aside from changing the kswapd behavior, GFP_ATOMIC should likely be allowed
to fallback into highatomic reserve in rmqueue_buddy() same as ALLOC_OOM can?