Re: [PATCH 2/2] mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES

[Johannes Weiner <hannes@cmpxchg.org>]

On Tue, Sep 22, 2026 at 02:06:34PM +0200, Vlastimil Babka (SUSE) wrote:
> On 9/21/26 4:39 PM, Johannes Weiner wrote:
> > 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HIGH
> > non-blocking allocations accesses reserves") stopped handing out
> > reserve access for ALLOC_NON_BLOCK on its own: the extra 25% below the
> > min watermark is now only granted on top of ALLOC_MIN_RESERVE. But the
> > flag was left in ALLOC_RESERVES, which produces something odd:
> > 
> > With the ALLOC_RESERVES match, __zone_watermark_unusable_free() doesn't
> > subtract the free highatomic pages for them. So in the slowpath, they
> > get to consume regular blocks below the min watermark by the number of
> > free highatomic pages. The highatomic reserve is capped at 1% of the
> > zone, which on any decently sized machine is a multiple of the min
> > watermark: GFP_NOWAIT can drain regular memory to zero.
> > 
> > The user-visible result is brutal hiccups during bursts of GFP_NOWAIT
> > allocations under memory pressure. On a 32G box with an anonymous
> > working set, swap, and a filled 290M highatomic reserve, a GFP_NOWAIT
> > burst drove regular free memory in the 28G Normal zone (min=60M) to
> > 28M, 0.8M and 0.6M in three runs. Swapout failed to allocate its swap
> > table, reclaim scanned 13M pages to reclaim 200k, page faults stalled
> > for tens to hundreds of milliseconds. The machine survives it, but not
> > by design: direct reclaimers eventually fail and start unreserving
> > highatomic blocks, until the allocation succeeds or the reserve is
> > gone and the OOM killer runs. That reserve exists for high-order
> > atomic allocations; here it is destroyed to bail out a GFP_NOWAIT
> > consumer that was never entitled to the memory.
> 
> This suggests to me that a LLM review of 1/2 spotted this issue and also
> (or you) constructed a test doing the GFP_NOWAIT bursts to confirm the
> impact, but it has not been observed in production? But if it was, can
> we make it clear?

Yes, and yes. The test is manufactured, I just pushed it to stick to a
realistic sequence of events. But it wasn't observed in the wild.

> The change itself is fine and we don't need ALLOC_NON_BLOCK in
> ALLOC_RESERVES. But I wonder if we should also make the
> __zone_watermark_unusable_free() check more precise, by using
> may_access_highatomic_reserves() there instead of ALLOC_RESERVES?
> Which would mean that the function should however also evaluate
> ALLOC_HIGHATOMIC, and restrict the other checks to order=0, to be usable
> from both callers.

I responded to this in 1/2 because it had more context.