AWS engineer says PostgreSQL throughput halved by Linux 7.0 — a simple revert may not save you

What happened?

It has been reported that an Amazon/AWS engineer, Salvatore Dipietro, found PostgreSQL throughput and latency dramatically worse on the development Linux 7.0 kernel — roughly half the throughput on a Graviton4 server versus prior kernels. Bisecting traced the regression to a change that restricted available kernel preemption modes, which pushes more time into a user-space spinlock and chokes PostgreSQL under load. A patch was posted to the kernel mailing list to restore PREEMPT_NONE as the default because the regression looks severe.

Upstream response: "Make PostgreSQL adapt"

Allegedly, that revert may not be accepted. Peter Zijlstra, the author of the preemption simplification, pushed back: “The fix here is to make PostgreSQL make use of rseq slice extension… That should limit the exposure to lock holder preemption (unless PostgreSQL is doing seriously egregious things).” RSEQ support was also upstreamed for Linux 7.0, so the kernel-side answer is to point database code at the new time-slice / restartable sequences mechanism rather than restoring the old preemption defaults.

Why it matters

This is more than a nerdy scheduler spat. Linux 7.0 is expected to go stable in about two weeks and will ship in Ubuntu 26.04 LTS later in April. If the proposed upstream stance holds, some PostgreSQL deployments may see serious performance drops until the database adapts to RSEQ — or until a kernel revert unexpectedly lands. Who’s left holding the bag? DBAs and cloud customers running PostgreSQL on newer kernels. Short term: watch for patches from PostgreSQL and test workloads on Linux 7.0 before you flip the switch.

Sources: phoronix.com, Hacker News