GoKawiil☕ Welcome to The Coder Cafe! On April 3, 2026, Salvatore Dipietro, an engineer at AWS, posted a patch to the Linux kernel mailing list. The reason: on a 96-vCPU Graviton4 machine running Linux 7.0, PostgreSQL throughput had dropped to roughly half of what it produced on Linux 6.x. In this post, we will trace what changed in Linux 7.0, how PostgreSQL manages memory, and what role memory pages play in making the problem appear (or disappear). Get cozy, grab a coffee, and let’s begin!
The Problem
Salvatore Dipietro ran pgbench (PostgreSQL’s standard benchmarking tool) on a Graviton4 processor with 96 vCPUs. The workload was a benchmark doing simple updates at scale factor 8,470 (i.e., roughly a 847 million row table), simulating 1,024 clients and 96 threads. A serious, high-parallelism load designed to stress the system.
The results were striking. Linux 7.0 delivered roughly half the throughput of Linux 6.x on the same hardware and workload:
Linux 6.x : 98,565 transactions per second
Linux 7.0: 50,751 transactions per second
To find where the time was going, Dipietro ran perf , a Linux profiling tool that samples what the CPU is actually doing. The result was unambiguous:
|- 56.03% - StartReadBuffer |- 55.93% - GetVictimBuffer |- 55.93% - StrategyGetBuffer |- 55.60% - s_lock # 55% of CPU
55% of the machine’s CPU time was spent inside a single function: s_lock . The culprit was traced back to a change in how Linux 7.0 schedules processes. Let’s start there.
What Is Preemption?
... continue reading