While just half-way through the Linux 6.19 merge window, over the weekend I began running some benchmarks of the current Linux 6.19 Git state compared to Linux 6.18 LTS stable. There are some minor performance improvements to note in a few of the tests on the first system I tested but also some regressions at this very early pre-RC1 state of the Linux 6.19 kernel.
During the wekend I ran some initial Linux 6.18 vs. Linux 6.19 Git benchmarks on a single-socket AMD EPYC 9655P server with 96 cores / 192 threads. This is the server build around the Supermicro H13SSL-N.
Linux 6.18 stable was compared to Linux 6.19 Git as of 6 December. The same Kconfig file was used and with the changes for v6.19 simply agreeing to the new defaults. No other changes were made to this AMD EPYC server besides the straight-forward kernel upgrade and the server otherwise running on Ubuntu 25.10.
Most troubling with these very early Linux 6.19 benchmarks was seeing big regressions to the mixed scheduler performance and socket performance as measured by the popular Stress-NG micro-benchmarks. These were the biggest regressions observed on Linux 6.19 Git out of the dozens of benchmarks I ran over the weekend.
Similar to the Stress-NG socket activity regression, running the Microsoft Ethr network program on the localhost was also showing Linux 6.19 in its early state performing worse than Linux 6.18.
Stress-NG did show the semaphores performance improving with Linux 6.19 Git.
The Hackbench scheduler benchmark also showed some small improvements on Linux 6.19.
The overall throughput measured by Stress-NG also was slightly better off on Linux 6.19 Git.
As was the context switching performance.
As for how the Linux 6.19 Git performance was translating into real-world performance for popular workloads, Linux 6.19 Git at this early stage was tending to run slightly slower than Linux 6.18…
For most of the real-world workloads the performance was similar or slightly worse on Linux 6.19 Git over Linux 6.18.
On a completely separate Ryzen desktop box, when trying out Linux 6.19 Git it was very rough with hitting file-system errors that did not occur when falling back to Linux 6.18 stable. That is still being explored more.
Once the merge window is over and the code churn settling down, I’ll be through with more benchmarks on more systems to see if those regressions in particular remain and are persistent across more hardware. If so looks like it will be some kernel bisecting and more benchmarking over the holidays – as always, if you enjoy my daily Linux hardware testing and news consider showing your support by going Phoronix Premium to help make everything possible during these difficult and frustrating times for web publishers.
