From: Salvatore Dipietro <dipiets@amazon.it>
To: <linux-kernel@vger.kernel.org>
Cc: <dipiets@amazon.it>, <alisaidi@amazon.com>, <blakgeof@amazon.com>,
<abuehaze@amazon.de>, <dipietro.salvatore@gmail.com>,
<willy@infradead.org>, Christian Brauner <brauner@kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
<linux-xfs@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>
Subject: [PATCH 0/1] iomap: avoid compaction for costly folio order allocation
Date: Fri, 3 Apr 2026 19:35:33 +0000 [thread overview]
Message-ID: <20260403193535.9970-1-dipiets@amazon.it> (raw)
We are reporting a throughput regression on PostgreSQL pgbench
(simple-update) on arm64 caused by commit 5d8edfb900d5 ("iomap:
Copy larger chunks from userspace") introduced in v6.6-rc1.
The regression manifests as a 0.75x throughput drop on a pgbench
simple-update workload with 1024 clients on a 96-vCPU arm64
system. When memory is even slightly fragmented, each failed
high-order allocation enters into __alloc_pages_slowpath() which
runs 2 memory compactions and drain_all_pages(), forcing all
vCPUs to release their pages. This is done multiple times, one
for each order (up to 6), until the allocation succeeds.
The patch makes costly-order folio allocations in the iomap
buffered write path purely opportunistic -- no direct reclaim,
no compaction, no drain_all_pages().
Combined with the separate PREEMPT_LAZY regression [1], the
total impact is a 2.87x throughput and latency loss.
1. Test environment
___________________
Hardware: 1x AWS EC2 m8g.24xlarge
(12x 1TB IO2 32000 iops RAID0 XFS)
OS: AL2023 (ami-03a8d3251f401ffca)
Kernel: next-20260331
Database: PostgreSQL 17
Workload: pgbench simple-update
1024 clients, 96 threads, 1200s duration
scale factor 8470, fillfactor=90, prepared protocol
2. Results
__________
Config Run1 Run2 Run3 Avg x
_____________________ _________ _________ _________ __________ ____
baseline 47242.39 53369.18 51644.29 50751.96 1.00
iomap patch 69305.92 66994.08 64603.33 66967.78 1.32
preempt-none [1] 92906.62 103976.03 98814.94 98565.86 1.94
iomap+preempt-none[1] 145904.53 146470.95 144728.91 145701.46 2.87
3. Reproduction
_______________
On the AWS EC2 m8g.24xlarge, install and run the PostgreSQL
database using the repro-collection repository like:
# Reproducer code:
git clone https://github.com/aws/repro-collection.git ~/repro-collection
# Setup and start PostgreSQL server in terminal 1:
~/repro-collection/run.sh postgresql SUT --ldg=127.0.0.1
# Run pgbench load generator in terminal 2:
PGBENCH_SCALE=8470 \
PGBENCH_INIT_EXTRA_ARGS="--fillfactor=90" \
PGBENCH_CLIENTS=1024 \
PGBENCH_THREADS=96 \
PGBENCH_DURATION=1200 \
PGBENCH_BUILTIN=simple-update \
PGBENCH_PROTOCOL=prepared \
~/repro-collection/run.sh postgresql LDG --sut=127.0.0.1
[1] https://lore.kernel.org/all/20260403191942.21410-1-dipiets@amazon.it/T/#t
Salvatore Dipietro (1):
iomap: avoid compaction for costly folio order allocation
fs/iomap/buffered-io.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
base-commit: 9147566d801602c9e7fc7f85e989735735bf38ba
--
2.50.1 (Apple Git-155)
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-04-03 19:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 19:35 Salvatore Dipietro [this message]
2026-04-03 19:35 ` [PATCH 1/1] iomap: avoid compaction for costly folio order allocation Salvatore Dipietro
2026-04-04 1:13 ` Ritesh Harjani
2026-04-04 4:15 ` Matthew Wilcox
2026-04-04 16:47 ` Ritesh Harjani
2026-04-04 20:46 ` Matthew Wilcox
2026-04-05 22:43 ` Dave Chinner
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=20260403193535.9970-1-dipiets@amazon.it \
--to=dipiets@amazon.it \
--cc=abuehaze@amazon.de \
--cc=alisaidi@amazon.com \
--cc=blakgeof@amazon.com \
--cc=brauner@kernel.org \
--cc=dipietro.salvatore@gmail.com \
--cc=djwong@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox