[STABLE 7.3.y] 0e05a469c294 ("mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations")

[STABLE 7.3.y] 0e05a469c294 ("mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations")

[Salvatore Dipietro]

Hi,

Please apply to 7.3.y:

  0e05a469c294 ("mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations")

It fixes a regression from 5d8edfb900d5 ("iomap: Copy larger chunks
from userspace"), in since v6.6: PostgreSQL pgbench on XFS runs at
0.38x throughput. Andrew and Vlastimil agreed to restore its
Cc: stable [1], but it was merged without the tag.

It depends on 6ee3d87b9408 and fe21f930d1e6, already queued for 7.3.

I'll send backports for 6.18.y, 6.12.y and 6.6.y separately.

[1] https://lore.kernel.org/all/1fc0caa5-43b1-487f-94cf-0d1aff4c03fd@kernel.org/

Thanks,
Salvatore



AMAZON DEVELOPMENT CENTER ITALY SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese di Milano Monza Brianza Lodi REA n. 2504859, Capitale Sociale: 10.000 EUR i.v., Cod. Fisc. e P.IVA 10100050961, Societa con Socio Unico

Re: [STABLE 7.3.y] 0e05a469c294 ("mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations")

[Sasha Levin]

On 2026-11-12, Salvatore Dipietro wrote:
> [STABLE 7.3.y] 0e05a469c294 ("mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations")
> Hi,
> Please apply to 7.3.y:
>   0e05a469c294 ("mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations")

Queued for 7.3, thanks.


-- 
Thanks,
Sasha