Re: [PATCH 0/4] mm: fix reclaim storms in defrag_mode

[Shakeel Butt]

On Thu, Jul 09, 2026 at 01:51:19PM -0400, Johannes Weiner wrote:
> On Wed, Jul 01, 2026 at 05:31:11PM -0700, Shakeel Butt wrote:
> > On Fri, Jun 26, 2026 at 02:21:16PM -0400, Johannes Weiner wrote:
> > > As we deployed vm.defrag_mode=1 into Meta production, some workloads
> > > regressed with recurring pressure spikes and swap storms (which in turn
> > > triggered userspace OOM rules on pressure and swap utilization levels).
> > > 
> > > Tracing pinned this to non-movable 
> > 
> > allocation?
> > 
> > > requests spinning and reclaiming
> 
>     ^^^
> 
> non-movable requests :)

I was just asking if you meant non-movable allocation requests.

> 
> > > unproductively when kswapd/kcompactd are overwhelmed. Direct reclaim
> > > predominantly frees up pages in movable blocks, but those requests
> > > cannot use that space under defrag_mode rules; 
> > 
> > Do we have these rules documented somewhere?
> 
> Kind of. The crux is that defrag_mode enforces ALLOC_NOFRAGMENT in the
> slowpath as well (whereas vanilla just does it in the fastpath). So
> it's documented to the extent that ALLOC_NOFRAGMENT is.

Ack.

> 
> > > and it is unlikely to
> > > free up whole blocks incidentally for __rmqueue_claim() to work.
> > > 
> > > This series fixes it by making non-movable requests participate in
> > > pageblock production in the allocator slowpath.
> > 
> > Sorry after reading above sentence I didn't get what those allocators will do
> > things differently after the series (I still have to go through the series).
> 
> Let me add:
> 
> [...] - meaning, they will invoke direct reclaim and direct compaction
> with pageblock_order.
> 
> Does that clarify it a bit?

Yes, this is more clear.