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

[Vlastimil Babka (SUSE)]

On 10/2/26 03:29, Andrew Morton wrote:
> 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.
>> 

Since it expands the impact of a pre-existing bug of nonblocking allocation
eating reserves [1] it shouldn't proceed to mainline without a fix for that
(Johannes posted it there but the review discussion got stalled).

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

I've also argued for not handling it as a hotfix [2]

[1] https://lore.kernel.org/all/9f415dc7-adad-4161-b20d-7c3173f50ff3@xxxxxxxxxx/

[2] https://lore.kernel.org/all/c6e2c1e1-a285-406e-a2b6-c09e05df91d8@xxxxxxxxxx/

> 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;
> _
>