Page allocator tweak restores 161% PostgreSQL write throughput

A pending Linux memory-management change stops costly high-order allocations marked non-retrying from running direct compaction and reclaim, recovering more than 160 percent throughput on a heavily concurrent PostgreSQL workload hammered by memory fragmentation.

Salvatore Dipietro of Amazon traced the damage to the iomap buffered write path, which for about three years has preferred larger multi-page folios when copying from userspace. Callers already signal that failure is acceptable and that they will fall back to smaller orders. Under fragmentation, each failed costly allocation still entered the full slow path anyway: direct compaction plus a system-wide page drain across every CPU. On a 96-vCPU arm64 host running pgbench simple-update with 1024 clients, that cost cut throughput to roughly 0.38x of the pre-regression level.

Dipietro's fix treats those no-retry costly requests as non-blocking from the start of the slow path. Direct reclaim, direct compaction, and the cross-CPU drain are skipped; background reclaim and compaction daemons are still woken so long-term defragmentation continues. Local-node transparent huge page attempts that depend on direct compaction are left alone.

On the same hardware and workload, the change lifted average throughput from about 59,000 to about 155,000 transactions per second, fully recovering (and slightly beating) a behavioural revert of the high-order write path.

Andrew Morton, who maintains the memory-management tree, asked why a three-year-old behaviour took so long to surface and requested a refined follow-up. Dave Chinner noted the wider history: filesystems and other subsystems have hit the same direct-compaction tax for years, XFS worked around it as early as the 5.17 era, and repeated reports argued the fix belonged in reclaim rather than at every call site. Christoph Hellwig has reviewed the approach favourably.