The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67369

    The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels

    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.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • microcode
    Senior Member
    • Mar 2013
    • 2374

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

    Comment

    • brauliobo
      Junior Member
      • Sep 2015
      • 28

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

      Comment

      • gutigone
        Phoronix Member
        • Sep 2016
        • 92

        #4
        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

        Comment

        • jrch2k8
          Senior Member
          • Jun 2009
          • 2095

          #5
          Originally posted by brauliobo View Post
          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.

          Comment

          • skeevy420
            Senior Member
            • May 2017
            • 8656

            #6
            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.

            Comment

            • Danny3
              Senior Member
              • Apr 2012
              • 2407

              #7
              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!

              Comment

              • bug77
                Senior Member
                • Dec 2009
                • 6519

                #8
                Originally posted by jrch2k8 View Post

                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.

                Comment

                • Michael
                  Phoronix
                  • Jun 2006
                  • 14308

                  #9
                  Originally posted by brauliobo View Post
                  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.
                  Last edited by Michael; 11 November 2019, 12:06 PM.
                  Michael Larabel
                  https://www.michaellarabel.com/

                  Comment

                  • perpetually high
                    Senior Member
                    • Mar 2017
                    • 1121

                    #10
                    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.

                    Comment

                    Working...
                    X