Re: [PATCH] mm/page_alloc: fix defrag_mode for non-reclaimable allocations

[Dmitry Ilvokhin]

On Mon, May 18, 2026 at 01:24:22PM -0700, Andrew Morton wrote:
> On Mon, 18 May 2026 16:37:36 +0000 Dmitry Ilvokhin <d@xxxxxxxxxxxx> wrote:
> 
> > When defrag_mode is enabled, ALLOC_NOFRAGMENT is enforced to prevent
> > migratetype fallbacks and keep pageblocks clean. The allocator relies on
> > reclaim and compaction to free pages of the correct type before allowing
> > fallback as a last resort.
> > 
> > However, non-reclaimable allocations such as GFP_ATOMIC cannot invoke
> > direct reclaim or compaction. With defrag_mode=1, these allocations hit
> > the !can_direct_reclaim bailout in __alloc_pages_slowpath() with
> > ALLOC_NOFRAGMENT still set, and fail without ever attempting a fallback.
> > 
> > This causes a large number of SLUB allocation failures for
> > skbuff_head_cache under network-heavy workloads, despite free memory
> > being available in other migratetype freelists.
> > 
> > Clear ALLOC_NOFRAGMENT and retry before giving up on allocations that
> > cannot reclaim, following the same pattern used after reclaim/compaction
> > exhaustion later in the slowpath.
> 
> Thanks.  Sashiko asked a couple of things:
> 
> 	https://sashiko.dev/#/patchset/20260518163736.173910-1-d@xxxxxxxxxxxx
> 
> I'm not sure what to make of the first one - we aren't holding any locks
> in there which prevent concurrent cpuset or zonelist alterations
> anyway (?).
> 
> But your change might violate the later comment `No "goto retry;" can be
> placed above this check * unless it can execute just once'?

Thanks for taking a look, Andrew.

Goto retry can execute at most once, since ALLOC_NOFRAGMENT is cleared
before the jump, so on the next iteration the condition is false and we
fall through to goto nopage. This is the similar to the existing
can_retry_reserves path.

Just for the sake of keeping everything in one place. Another point
Sashiko raised.

"Will allocations hitting this PF_MEMALLOC check, or the __GFP_NORETRY check
further down in the function, still fail prematurely under defrag_mode=1?
Because these terminal error paths also jump directly to the nopage label,
they skip the normal ALLOC_NOFRAGMENT clearing at the bottom of the slowpath.
Should we also clear ALLOC_NOFRAGMENT and retry for these paths so they are
allowed to fall back rather than failing outright?"

I think by the time we reach the PF_MEMALLOC check, ALLOC_NOFRAGMENT has
already been cleared, since we set only ALLOC_NO_WATERMARKS and
ALLOC_KSWAPD in reserve_flags, when PF_MEMALLOC is set.

For GFP_NORETRY, we can do direct reclaim (compared to GFP_ATOMIC case),
so we either succeed or not, we don't need another round.