Skip to content

iomap: avoid compaction for costly folio order allocation

Salvatore Dipietro linux-fsdevel linux-mm linux-xfs lkml stable 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest1 patch 24 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/1iomap: avoid compaction for costly folio order allocationfs/iomap/buffered-io.c+14 -124 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/1] iomap: avoid compaction for costly folio order allocation

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/[email protected]/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

Signature · 6 lines
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

Read the cover letter in its thread