Re: [PATCH v6] mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations

[Andrew Morton]

On Thu, 1 Oct 2026 08:21:51 +0000 Salvatore Dipietro <dipiets@xxxxxxxxx> wrote:

> Commit 5d8edfb900d5 ("iomap: Copy larger chunks from userspace")
> introduced high-order folio allocations in the iomap buffered write
> path.  When memory is fragmented, each failed costly-order allocation
> enters __alloc_pages_slowpath() which runs direct reclaim, direct
> compaction and drain_all_pages(), causing a 0.38x throughput drop on
> PostgreSQL pgbench (simple-update) with 1024 clients on a 96-vCPU arm64
> system.
> 
> The root issue is that direct reclaim and direct compaction are too
> expensive for hot allocation paths that have fallbacks to smaller
> allocations.  __filemap_get_folio_mpol() already marks higher-order
> allocations with __GFP_NORETRY | __GFP_NOWARN, signalling that the
> caller can handle failure.  However, the page allocator still enters the
> full blocking slowpath for costly orders with __GFP_NORETRY, which is
> unnecessarily aggressive when the caller will simply retry at a lower
> order.
> 

Thanks, I'll update mm-hotfixes to this version.

Here's what changed:

--- a/mm/page_alloc.c~mm-page_alloc-avoid-direct-reclaim-and-compaction-for-costly-__gfp_noretry-allocations
+++ a/mm/page_alloc.c
@@ -4930,8 +4930,11 @@ retry:
 		 * Reclaim/compaction cannot run, so defrag_mode's strategy
 		 * of enforcing ALLOC_NOFRAGMENT cannot be fulfilled. Allow
 		 * fallbacks rather than failing the allocation outright.
+		 * Not for __GFP_NORETRY: those have a cheap lower order
+		 * fallback, so failing beats fragmenting.
 		 */
 		if (defrag_mode && (alloc_flags & ALLOC_NOFRAGMENT) &&
+		    !(gfp_mask & __GFP_NORETRY) &&
 		    (gfp_mask & __GFP_KSWAPD_RECLAIM)) {
 			alloc_flags &= ~ALLOC_NOFRAGMENT;
 			goto retry;
_