The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels

[phoronix]

Phoronix: The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels

With the Linux 5.4 kernel set to be released in the next week or two, here is a look at the performance going back to the days of Linux 5.14 from early 2018. At least the Linux kernel continues picking up many new features as due to security mitigations and other factors the kernel performance continues trending lower.

http://www.phoronix.com/vr.php?view=28453

[microcode]

But the kernel is stunning and brave now, and that's all that matters.

[brauliobo]

Michael shouldnt PTS automatically track the commit on each regression and email LKML with the commit and the performance impact??

[gutigone]

With the Linux 5.4 kernel set to be released in the next week or two, here is a look at the performance going back to the days of Linux 5.14 from early 2018.

5.14?! :P

[jrch2k8]

Michael shouldnt PTS automatically track the commit on each regression and email LKML with the commit and the performance impact??

Those are probably not regression but mitigations hits and those won't go away until those problem are fixed in silicon in the future, in fact expect it to get even worse from now on since every time a new one is discovered it seems to be way worse than the previous ones, specially for Intel CPUs.

[skeevy420]

What would be interesting would be to pick something like 4.14 or 4.9 that's both older and still receives updates and see how it performs over time based on or around stable point release dates since as fixes and whatnot are backported, it seems like an older LTS would make a decent candidate for performance over time tests.

I'm glad the current LTS fares well in the geometric. Gains and falls are to be expected with random point releases whereas, well, IMHO, the LTS kernels, ideally, should perform the best overall since they're meant to be used long-term.

As always, thanks for the benchmarks Michael.

[Danny3]

Awful... just awful.
I hate when developers care only about security and do the changes no matter the costs.
I bet none of them used Phoronix Test Suite or other benchmarking tool before pushing these changes into the Linux kernel.
This is really disappointing!

[bug77]

Those are probably not regression but mitigations hits and those won't go away until those problem are fixed in silicon in the future, in fact expect it to get even worse from now on since every time a new one is discovered it seems to be way worse than the previous ones, specially for Intel CPUs.

Virtually all hardware fixes will retain the performance hit. Because the only fix to speculative execution weaknesses is "don't do speculative execution". That, or "do speculative execution and cleanup afterwards", which in many cases defeats the purpose.

I suspect we're going to need serious silicon redesign to get speculative execution back into safe territory without performance penalties.

[Michael]

Michael shouldnt PTS automatically track the commit on each regression and email LKML with the commit and the performance impact??

PTS/Phoromatic has that support but doing per-commit for kernel is quite time consuming but the bigger blocker is no sponsor for supporting such testing.... I did the daily testing at LinuxBenchmarking.com as proof of concept but money is running very tight and with no one sponsoring said kernel tests, been pulling back due to energy costs and associated cooling costs adding up.

Edit: To further add, in the world of more resources, the more logical thing to do in the case of the kernel would be per-Git-merge testing and then potentially from there per-commit / git-bisect tests of branches when there is a change to the kernel.

[perpetually high]

Big yikes. Thanks for ringing the alarm.

The other day I was curious on the ctx_clock test and ran it without mitigations=off on my i5-4670K, and it was 997!!! With mitigations=off, it was back down to 142. I'm so grateful we can turn that sh*t off on our notebooks/desktops.