Re: [PATCH v2] mm: page_alloc: make defrag_mode retries follow the promoted order

From: Kiryl Shutsemau

Date: Wed Oct 07 2026 - 09:15:32 EST


On Tue, Oct 06, 2026 at 04:41:22PM -0700, Andrew Morton wrote:
> On Tue, 6 Oct 2026 10:18:13 +0100 Kiryl Shutsemau <kirill@xxxxxxxxxxxxx> wrote:
>
> > From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
> >
> > Since commit 7e8756d7ad22 ("mm: page_alloc: fix non-movable reclaim
> > storm in defrag_mode"), direct reclaim and compaction for non-movable
> > requests under defrag_mode run at pageblock_order, to produce the whole
> > blocks that ALLOC_NOFRAGMENT needs. The retry decisions that follow
> > still use the request order. An order-0 request can therefore retry
> > indefinitely without ever reaching the ALLOC_NOFRAGMENT fallback:
> >
> > ...
> >
> > In a VM reproducer (32G, defrag_mode, inode churn under memory.low):
> >
> > before after
> > should_reclaim_retry() calls 63M 293k
> > peak memory pressure (PSI some avg10) 99% 12%
> >
> > File creation runs 5.7x faster.
>
> > Fixes: 7e8756d7ad22 ("mm: page_alloc: fix non-movable reclaim storm in defrag_mode")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Assisted-by: LLM
> > Signed-off-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>
> > ---
> > v2:
> > - keep the compaction priority floor and the COMPACT_SUCCESS retry
> > limit on the request order, so non-costly requests still escalate to
> > SYNC_FULL before falling back (Harry Yoo, Johannes Weiner)
> > - compute the promoted order once in __alloc_pages_slowpath() and pass
> > it to direct reclaim, direct compaction and the retry helpers, instead
> > of each of them deriving it (Harry Yoo)
>
> Thanks. That's a fairly large update. v2 diff is below.
>
> Are we sure about cc:stable? Or even 7.3-rcX? It's a pretty big
> change.

I think defrag_mode is not widely used. Maybe only in Meta.

What about keeping cc:stable, but only submit it to Linus for v7.4-rc1?

By the time we would have the patch battle-tested in the fleet.

--
Kiryl Shutsemau / Kirill A. Shutemov