Re: [PATCH 6.18.y] mm: page_alloc: make defrag_mode retries follow the promoted order

[Harry Yoo <harry@kernel.org>]

On Mon, Nov 09, 2026 at 11:30:06AM +0000, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
> 
> commit 4cd78a2dcfbb13f049f841b98763896a3d1d7750 upstream.
> 
> 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:
> 
> - Reclaim at pageblock_order gives up after one pass as soon as a zone
>   looks compaction_ready(), and do_try_to_free_pages() then returns 1
>   even though nothing was reclaimed. It returns before the retry that
>   would reclaim memory.low-protected cgroups, so when most memory is
>   protected, the pass that did run finds next to nothing.
> 
> - Compaction at pageblock_order fails or is deferred.
> 
> - should_reclaim_retry() takes the reported progress as progress for
>   the order-0 request and resets no_progress_loops. The request
>   retries.
> 
> Order 1-3 requests loop the same way, and should_compact_retry() also
> checks their pageblock_order compaction result against the request order.
> 
> On a production host (64G, defrag_mode, memory.low covering most of the
> workload), 95% of direct reclaim runs were order-9 runs that returned 1
> with nothing reclaimed, at up to 60k runs per second.  Across ~200M
> should_reclaim_retry() calls in a day, no_progress_loops never left 0.
> The spinning allocations were SLUB slab refills for inode and dentry
> caches.  The time spent registers as memory pressure, and pressure-based
> OOM killing takes down both workloads and system services.
> 
> For promoted requests:
> 
> - Reclaim progress does not reset no_progress_loops, as for costly
>   orders.
> 
> - should_compact_retry() checks the compaction result at the promoted
>   order and does not retry COMPACT_SKIPPED, since the request can fall
>   back. The compaction priority floor and the COMPACT_SUCCESS retry
>   limit stay those of the request order, so a non-costly request still
>   gets its COMPACT_PRIO_SYNC_FULL pass before it falls back.
> 
> When a promoted request takes the fallback, reset the retry counters, so
> that the fallback attempt gets a full retry budget before the OOM killer
> is considered.  A request whose reclaim was not promoted spent its budget
> on the request itself and keeps its counters, as Usama Arif pointed out.
> 
> __alloc_pages_slowpath() computes the promoted order once per iteration
> and keeps it in alloc_context for direct reclaim, direct compaction and
> the two retry helpers, so no callee has to recompute it.  Harry Yoo asked
> for the promoted order to be explicit rather than derived in each callee,
> and Vlastimil Babka suggested alloc_context over new function parameters.
> 
> 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.
> 
> [kas@kernel.org: s/order_nofrag_promoted/order_defrag_promoted/, per hannes]
>   Link: https://lore.kernel.org/atDL-nSFP2KVU7cI@thinkstation
> Link: https://lore.kernel.org/as5q14OsbK2CmOrh@thinkstation
> Fixes: 7e8756d7ad22 ("mm: page_alloc: fix non-movable reclaim storm in defrag_mode")
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Assisted-by: LLM
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Harry Yoo <harry@kernel.org>
> Cc: Usama Arif <usama.arif@linux.dev>
> Cc: Suren Baghdasaryan <surenb@google.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Brendan Jackman <brendan.jackman@linux.dev>
> Cc: Zi Yan <ziy@nvidia.com>
> Cc: Shakeel Butt <shakeel.butt@linux.dev>
> Cc: <stable@vger.kernel.org>
> [ kas: alloc_context is in mm/internal.h and compaction_zonelist_suitable()
>   takes no gfp_mask in 6.18. 6.18 also tries compaction once before the
>   retry loop; set reclaim_compact_order there as well, or that attempt
>   sees order 0 and is skipped. ]
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> ---

The backport looks good to me,
Acked-by: Harry Yoo (Meta) <harry@kernel.org>

-- 
Cheers,
Harry / Hyeonggon