Re: [PATCH v2 4/4] mm: page_alloc: fix non-movable reclaim storm in defrag_mode

[Johannes Weiner]

On Fri, Jul 24, 2026 at 03:09:49PM +0000, Brendan Jackman wrote:
> On Wed Jul 22, 2026 at 2:56 PM UTC, Johannes Weiner wrote:
> > As we deployed defrag_mode into Meta production, pressure spikes and
> > excessive swapping were observed on some workloads. Tracing confirmed
> > that this is unmovable/reclaimable requests spinning in the allocator
> > and direct reclaim, causing excessive amounts of swap.
> >
> > The initial plan for defrag_mode was to rely on kswapd/kcompactd to
> > produce blocks, and if those are overwhelmed under high pressure, let
> > the allocator fall back (__rmqueue_steal()) after its retry loops.
> > However, that retrying results in more reclaim on some of these
> > workloads than we'd hoped, sometimes excessively so, spurred on by the
> > !costly order conditions in should_reclaim_retry().
> >
> > The storms are dependent on the request type. Reclaim will inevitably
> > make room in existing movable blocks, since that's where the LRU pages
> > live. So if movable requests retry on reclaim, they make progress.
> >
> > When non-movable requests spin in reclaim that isn't productive. They
> > cannot use the individually freed pages, and the process is unlikely
> > to accidentally free whole blocks to meet the ALLOC_NOFRAGMENT bar.
> > They spin and overreclaim excessively, which tanks performance and
> > triggers userspace guards like swap exhaustion or pressure based OOM.
> >
> > To fix this, send non-movable requests, regardless of order, into
> > pageblock reclaim/compaction. This way, they help move things along to
> > meet the ALLOC_NOFRAGMENT bar. After this patch, the reclaim storms
> > and excess OOM rates are no longer observed in production.
> >
> > The longer-term plan is still to have all requests, including the
> > movable ones, help make blocks to spread the cost of defragmenting
> > more evenly and fairly; combined with proper watermarking to reduce
> > allocation latencies in the common case. However, doing this naively
> > unearths scaling and concurrency limitations in compaction that need
> > to be addressed first. Promoting just non-movables for now is the
> > minimally viable bug fix for the above issue.
> 
> Please forgive the noob question, I'm still struggling to get a really
> good mental handle on this stuff. But what about compact_first here?
> When we're promoting the order for compaction does it also make sense to
> promote compaction itself?

My understanding is that this is just an optimization for requests
that are more likely shape-limited (block contiguity) rather than
capacity-limited (free order-0). In that case we do a quick async
compaction attempt first and skip a potentially unnecessary but still
disruptive reclaim invocation.

However, it does seem to me there is a bit of redundancy between the
allocator and reclaim: direct reclaim also has that early bailout
condition on compaction_ready() for costly orders.

In defrag_mode, since reclaim is promoted to pageblock_order (costly),
we always bail reclaim on compaction_ready(). So I would assume there
is not much difference from which we call first - although I have not
tested it.

> I'm aware you said "minimally viable bug fix" so it's fine if this falls
> outside of that, I'm just trying to poke around to improve my
> understanding.

It works in production, but I'm not entirely happy yet with the retry
logic. I also find it somewhat difficult to understand, especially the
split between should_reclaim_retry() and should_compact_retry().

I'm working on unifying them and put the defrag_mode order promotion
directly into the slowpath function. This way we can use "work_order"
and "order" throughout the functions and its callees as appropriate.

But yeah this is follow-up work to the fix here.