Announcement

Collapse
No announcement yet.

The Spectre/Meltdown Performance Impact On Linux 4.20, Decimating Benchmarks With New STIBP Overhead

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

  • The Spectre/Meltdown Performance Impact On Linux 4.20, Decimating Benchmarks With New STIBP Overhead

    Phoronix: The Spectre/Meltdown Performance Impact On Linux 4.20, Decimating Benchmarks With New STIBP Overhead

    As outlined yesterday, significant slowdowns with the Linux 4.20 kernel turned out to be due to the addition of the kernel-side bits for STIBP (Single Thread Indirect Branch Predictors) for cross-HyperThread Spectre Variant Two mitigation. This has incurred significant performance penalties with the STIBP support in its current state with Linux 4.20 Git and is enabled by default at least for Intel systems with up-to-date microcode. Here are some follow-up benchmarks looking at the performance hit with the Linux 4.20 development kernel as well as the overall Spectre and Meltdown mitigation impact on this latest version of the Linux kernel.

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

  • #2
    This is the biggest disaster for Intel CPUs with HT that I can imagine.
    It makes HyperThreading technology practically useless for Linux machines.
    Probably this is why HT seemed to having been disabled during the 96 core (Edit: dual socket) Cascade Lake presentation?
    Last edited by oooverclocker; 11-17-2018, 02:38 PM.

    Comment


    • #3
      If AMD really doesn't end up needing this patch, it's pretty interesting to me how the performance gap has narrowed so dramatically.
      In another perspective, AMD's IPC was never really that far behind, it's just that Intel for a long while got a big performance lead due to these vulnerabilities.

      I'm curious how much Windows is affected by this. I haven't seen any benchmarks for that yet.

      Comment


      • #4
        Originally posted by oooverclocker View Post
        This is the biggest disaster for Intel CPUs with HT that I can imagine.
        It makes HyperThreading technology practically useless for Linux machines.
        Probably this is why HT seemed to having been disabled during the 96 core (Edit: dual socket) Cascade Lake presentation?
        I believe this is a test of all spectre+meltdown mitigations. STIBP alone doesn't cause as much of a regression.

        Comment


        • #5
          Originally posted by Wielkie G View Post

          I believe this is a test of all spectre+meltdown mitigations. STIBP alone doesn't cause as much of a regression.
          There's both. The ones going from 4.19 to 4.20 is just the impact of STIBP while the tests labeled with mitigations disabled are obviously with all spec/melt code turned off.
          Michael Larabel
          http://www.michaellarabel.com/

          Comment


          • #6
            From what i have studied until now, AMD architectures are 99.99% invulnerable to Spectre V2. There is a theoretical vulnerability that is acknowledged by AMD but almost all security experts agree that is practically impossible to really affect real world machines. Unless some independent (not Intel PR) researchers actually demonstrate an AMD practical exploit for V2 then there is no reason to enable the mitigation by default. Anything else should be a scandal, since it allows Intel to still pretend to have a higher IPC advantage than they have (?). Let it off by default on AMD and let those paranoid and/or using security-critical systems to enable it themselves.

            Comment


            • #7
              Originally posted by Wielkie G View Post
              I believe this is a test of all spectre+meltdown mitigations. STIBP alone doesn't cause as much of a regression.
              Considering Michael's answer and the fact that the current kernel version performs often almost identically with 4.20 without mitigations, it is still unbelievably much negative performance impact when I estimate the intersection of the numbers, more than ever before.
              Especially after looking at the glibc benchmark I think it's better to simply drop HT completely. Is this even a full mitigation now? - Deactivating HT gives a full mitigation against many vulnerabilities and the performance impact is much more consistent, it might even have positive effects for some tasks. Of course it's not that easy to decide for datacenters like for home users.

              Comment


              • #8
                Originally posted by oooverclocker View Post
                This is the biggest disaster for Intel CPUs with HT that I can imagine.
                It makes HyperThreading technology practically useless for Linux machines.
                Probably this is why HT seemed to having been disabled during the 96 core (Edit: dual socket) Cascade Lake presentation?
                The patch changing behavior did not exist at the time, although showing off performance that they knew that they would lose could have motivated turning it off if true,

                Comment


                • #9
                  Originally posted by TemplarGR View Post
                  From what i have studied until now, AMD architectures are 99.99% invulnerable to Spectre V2. There is a theoretical vulnerability that is acknowledged by AMD but almost all security experts agree that is practically impossible to really affect real world machines. Unless some independent (not Intel PR) researchers actually demonstrate an AMD practical exploit for V2 then there is no reason to enable the mitigation by default. Anything else should be a scandal, since it allows Intel to still pretend to have a higher IPC advantage than they have (?). Let it off by default on AMD and let those paranoid and/or using security-critical systems to enable it themselves.
                  AMD recommends a mitigation be enabled for Spectre v2 in their official response, although they discourage STIBP:

                  https://developer.amd.com/wp-content...ch_Control.pdf

                  The kernel patch that turns it on does not discriminate between AMD and Intel. It is bizarre that it is not being enabled. If I had access to a recent AMD system, I could figure out why.
                  Last edited by ryao; 11-17-2018, 03:38 PM.

                  Comment


                  • #10
                    Is there a way to compensate this involution!?

                    Comment

                    Working...
                    X