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

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

[Andrew Morton]

On Mon, 18 May 2026 16:37:36 +0000 Dmitry Ilvokhin <d@ilvokhin.com> 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@ilvokhin.com

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'?

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@ilvokhin.com> 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@ilvokhin.com
> 
> 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.

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

[Johannes Weiner]

On Tue, May 19, 2026 at 01:47:52PM +0000, Dmitry Ilvokhin wrote:
> 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@ilvokhin.com> 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@ilvokhin.com
> > 
> > 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.

Yes, it's just a one-off retry with relaxed fragmentation rules, no
need to re-evaluate the cpuset. So this looks fine to me.

> 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.

Yes, that's correct. alloc_flags gets overwritten, losing NOFRAGMENT,
for privileged requests. And then we retry with that already.

> 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.

This is an interesting question.

GFP_NORETRY can reclaim and compact once, yes, but ALLOC_NOFRAGMENT is
still a higher bar, increasing the likelihood of failure.

However, unlike GFP_ATOMIC, GFP_NORETRY are usually speculative
allocations with reasonable fallback options (like slub's optimistic
higher order requests).

The idea behind defrag_mode is to not fragment until the alternative
is OOM. For GFP_ATOMIC, failing is an OOM-like event. For the other
nopage cases, it's more about "my favorite thing isn't available".

So I'd say let's fix GFP_ATOMIC and leave the other cases alone unless
somebody specifically brings it up as an issue.

However, there is one catch: GFP_ATOMIC is not its own flag. You're
gating on can_direct_reclaim which is also true for optimistic things
like mTHP allocations (GFP_TRANSHUGE_LIGHT e.g.). We don't want to
fragment for those, either.

So I think you'd want to check at least if __GFP_KSWAPD_RECLAIM is set
(which it is for GFP_ATOMIC) to decide between fragmenting and
failing. If the caller doesn't even set that, it's a good indicator
that they're purely speculative, and failing is the better option.

With that,

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

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

[Dmitry Ilvokhin]

On Tue, May 19, 2026 at 11:28:39AM -0400, Johannes Weiner wrote:
> On Tue, May 19, 2026 at 01:47:52PM +0000, Dmitry Ilvokhin wrote:
> > 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@ilvokhin.com> 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@ilvokhin.com
> > > 
> > > 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.
> 
> Yes, it's just a one-off retry with relaxed fragmentation rules, no
> need to re-evaluate the cpuset. So this looks fine to me.
> 
> > 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.
> 
> Yes, that's correct. alloc_flags gets overwritten, losing NOFRAGMENT,
> for privileged requests. And then we retry with that already.
> 
> > 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.
> 
> This is an interesting question.
> 
> GFP_NORETRY can reclaim and compact once, yes, but ALLOC_NOFRAGMENT is
> still a higher bar, increasing the likelihood of failure.
> 
> However, unlike GFP_ATOMIC, GFP_NORETRY are usually speculative
> allocations with reasonable fallback options (like slub's optimistic
> higher order requests).
> 
> The idea behind defrag_mode is to not fragment until the alternative
> is OOM. For GFP_ATOMIC, failing is an OOM-like event. For the other
> nopage cases, it's more about "my favorite thing isn't available".
> 
> So I'd say let's fix GFP_ATOMIC and leave the other cases alone unless
> somebody specifically brings it up as an issue.
> 
> However, there is one catch: GFP_ATOMIC is not its own flag. You're
> gating on can_direct_reclaim which is also true for optimistic things
> like mTHP allocations (GFP_TRANSHUGE_LIGHT e.g.). We don't want to
> fragment for those, either.
> 
> So I think you'd want to check at least if __GFP_KSWAPD_RECLAIM is set
> (which it is for GFP_ATOMIC) to decide between fragmenting and
> failing. If the caller doesn't even set that, it's a good indicator
> that they're purely speculative, and failing is the better option.

Thanks for taking a look, Johannes.

Makes sense to me. I'll add a check for __GFP_KSWAPD_RECLAIM.

> 
> With that,
> 
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>