On 8/30/24 17:43, Matt Fleming wrote: > On Thu, Aug 29, 2024 at 4:48 PM Vlastimil Babka <vbabka@xxxxxxx> 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?
