From: Salvatore Dipietro <dipiets@amazon.it>
To: <stable@vger.kernel.org>
Cc: <dipietro.salvatore@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>, <linux-mm@kvack.org>
Subject: [PATCH 6.18.y 0/3] mm/page_alloc: fix iomap buffered write regression from 5d8edfb900d5
Date: Fri, 13 Nov 2026 11:02:56 +0000 [thread overview]
Message-ID: <20261113110259.2901456-1-dipiets@amazon.it> (raw)
Backport of 0e05a469c294 ("mm/page_alloc: avoid direct reclaim and
compaction for costly __GFP_NORETRY allocations") to 6.18.y. It fixes a
regression from 5d8edfb900d5 ("iomap: Copy larger chunks from userspace",
v6.6), which slows buffered writes under memory fragmentation.
Andrew and Vlastimil agreed it should go to stable [1].
Patches 1-2 are its prerequisites from the same mainline merge (Cc:
stable), only moved from mm/page_alloc.h to mm/internal.h. Patch 3 is
adjusted for this tree, see its changelog. Acks from Vlastimil and
Johannes on these adjustments would be appreciated.
Built, booted and tested with pgbench simple-update (PostgreSQL 18.6,
1024 clients, 96 threads, 1200s) on m8g.24xlarge (96 vCPU arm64),
12x io2 RAID0 XFS, mean of 3 runs:
v6.18.63 87,278 TPS
v6.18.63 + series 154,670 TPS (+77.2%)
[1] https://lore.kernel.org/all/1fc0caa5-43b1-487f-94cf-0d1aff4c03fd@kernel.org/
Johannes Weiner (2):
mm: page_alloc: do not give all non-blocking requests reserve access
mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES
Salvatore Dipietro (1):
mm/page_alloc: avoid direct reclaim and compaction for costly
__GFP_NORETRY allocations
mm/internal.h | 14 ++++++++------
mm/page_alloc.c | 16 ++++++++++++++--
2 files changed, 22 insertions(+), 8 deletions(-)
--
2.50.1
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
next reply other threads:[~2026-11-13 11:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 11:02 Salvatore Dipietro [this message]
2026-11-13 11:02 ` [PATCH 6.18.y 1/3] mm: page_alloc: do not give all non-blocking requests reserve access Salvatore Dipietro
2026-11-13 11:02 ` [PATCH 6.18.y 2/3] mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES Salvatore Dipietro
2026-11-13 11:02 ` [PATCH 6.18.y 3/3] mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations Salvatore Dipietro
2026-11-13 19:09 ` [PATCH 6.18.y 0/3] mm/page_alloc: fix iomap buffered write regression from 5d8edfb900d5 Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261113110259.2901456-1-dipiets@amazon.it \
--to=dipiets@amazon.it \
--cc=akpm@linux-foundation.org \
--cc=dipietro.salvatore@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=stable@vger.kernel.org \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.