Announcement

Collapse
No announcement yet.

A Look At The Linux Kernel Performance From 4.10 To 4.20

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • A Look At The Linux Kernel Performance From 4.10 To 4.20

    Phoronix: A Look At The Linux Kernel Performance From 4.10 To 4.20

    Here is a look at how the Linux kernel performance has evolved since Linux 4.10, which was released back in February of 2017, up through the current Linux 4.20 development cycle ahead of its debut at the end of December or early January. All of the Linux kernel benchmarks were done on the same venerable Intel Core i7 5960X system.

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

  • #2
    Could I disable the Spectre/Meltdown patch only for GIMP and music creation programs where performance is desired? I have AMD Kaveri A8-7600 APU.

    Comment


    • #3
      Originally posted by GraysonPeddie View Post
      Could I disable the Spectre/Meltdown patch only for GIMP and music creation programs where performance is desired? I have AMD Kaveri A8-7600 APU.
      If you have an AMD chip, you are safe from Meltdown. Only Intel's x86 chips are vulnerable to Meltdown.
      Last edited by torsionbar28; 26 November 2018, 05:02 PM.

      Comment


      • #4
        AMD isn't safe from Spectre, am I right?

        Comment


        • #5
          Originally posted by GraysonPeddie View Post
          AMD isn't safe from Spectre, am I right?
          It is safe if mitigated

          Code:
          > grep . /sys/devices/system/cpu/vulnerabilities/* | cut -c41-
          l1tf:Not affected
          meltdown:Not affected
          spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
          spectre_v1:Mitigation: __user pointer sanitization
          spectre_v2:Mitigation: Full AMD retpoline

          Comment


          • #6
            Originally posted by torsionbar28 View Post
            If you have an AMD chip, you are safe from Meltdown. Only Intel's x86 chips are vulnerable to Meltdown.
            There is new Meltdown-BR subvariant where AMD might be affected too, but it is about 32-bit x86... So if you are on 64bit you are safe

            Or at least AMD didn't responded on this newly identified BR variant yet
            Last edited by dungeon; 26 November 2018, 06:51 PM.

            Comment


            • #7
              Michael, if i may suggest, reading this on mobile you can't easily see if a chart has 'higher is better' or 'lower is better'. Could this be done via colors? E.g. - red bars mean lower is better, blue bars mean higher is better...?

              Comment


              • #8
                Thank you for this Michael!

                I wish the kernel had some automated stuff like that happening continuously to find less than desirable commits. Maybe you could get subsidized by the Linux Foundation or along for doing this daily?

                Comment


                • #9
                  Originally posted by geearf View Post
                  Thank you for this Michael!

                  I wish the kernel had some automated stuff like that happening continuously to find less than desirable commits. Maybe you could get subsidized by the Linux Foundation or along for doing this daily?
                  I've had the infrastructure to do it daily (now bi-daily) for years albeit don't focus on it too much due to no funding/time to support the effort, sadly. So I also don't run many interesting tests due to time/energy requirements and then also cut it back to being bi-daily due to electrical costs and capacity -

                  http://linuxbenchmarking.com/?daily-...x-kernel-tests
                  Michael Larabel
                  http://www.michaellarabel.com/

                  Comment


                  • #10
                    Originally posted by Michael View Post

                    I've had the infrastructure to do it daily (now bi-daily) for years albeit don't focus on it too much due to no funding/time to support the effort, sadly. So I also don't run many interesting tests due to time/energy requirements and then also cut it back to being bi-daily due to electrical costs and capacity -

                    http://linuxbenchmarking.com/?daily-...x-kernel-tests
                    I think this is awesome. You'd still need the part that understands that something is wrong and bisect it, but you probably already have that too. (It might also be good to find the helpful commits, because sometimes it may not have been anticipated to be that useful, and the approach could be reused somewhere else.)
                    I really wish you'd get some corporate help here, this is important stuff!

                    Same thing for the graphics side too of course.

                    Thank you!

                    Comment

                    Working...
                    X