Salvatore Dipietro of Amazon/AWS reported a throughput and latency regression for PostgreSQL. They found Linux 7.0 in its near-final form delivering around 0.51x the throughputof prior kernels on a Graviton4 server due to now much more time being spent in a user-space spinlock.
Bisecting the regression was traced back to the Linux 7.0 change of restricting the available preemption modes for the kernel. That change was previously covered on Phoronix within Linux 7.0 To Focus Just On Full & Lazy Preemption Models For Up-To-Date CPU Archs and in turn upstreamed with the Linux 7.0 scheduler updates.
As a result, yesterday posted to the Linux kernel mailing list was a patch to restore PREEMPT_NONE as the default given the severity of the reported regression.
While fixing an active performance regression, it looks like this change to restore PREEMPT_NONE as the default preemption model might not be picked up. Peter Zijlstra who authored the original code simplifying the preemption modes has responded that the "fix" is to make PostgreSQL make use of the Restartable Sequences (RSEQ) time slice extension. That time slice extension support was also upstreamed for Linux 7.0.
"The fix here is to make PostgreSQL make use of rseq slice extension:https://lkml.kernel.org/r/[email protected]
That should limit the exposure to lock holder preemption (unless PostgreSQL is doing seriously egregious things)."
So if that stands and shifting the blame to PostgreSQL, Linux 7.0 stable could lead to a significant drop for PostgreSQL performance in some scenarios until that popular database server is updated.
Linux 7.0 stable is due out in about two weeks. This is also the kernel version powering Ubuntu 26.04 LTS to be released later in April.