Re: [PATCH v4] mm/page_alloc: avoid direct compaction for costly __GFP_NORETRY allocations

[Andrew Morton]

On Fri, 4 Sep 2026 11:56:28 +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 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.

Is there anything particularly unusual about this test case?

> Results (average of 3 runs, TPS):
> 
>   Config                   Avg TPS      % vs Baseline
>   baseline (no patch)       59,408       -
>   With this patch          155,409      +161.6%

Is this back to pre-5d8edfb900d5 performance?

> Link: https://lore.kernel.org/all/20260403193535.9970-1-dipiets@xxxxxxxxx/T/#t [v1]
> Link: https://lore.kernel.org/linux-mm/20260420161404.642-1-dipiets@xxxxxxxxx/T/#u [v2]
> Link: https://lore.kernel.org/all/20260710143437.12379-1-dipiets@xxxxxxxxx/T/#u [v3]
> Fixes: 5d8edfb900d5 ("iomap: Copy larger chunks from userspace")

That's three years old.  v6.10.  

This is not good.  Can you think of an exceptional reason why this took
so long to surface, or is it simply that our testing isn't good?

And thanks for fixing it.

AI review asked a few serious-looking questions:
	https://sashiko.dev/#/patchset/20260904115629.3993331-1-dipiets@xxxxxxxxx