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

  • #11
    schmidtbag Windows is fine. Been gaming on it for the past three weeks straight.

    Comment


    • #12
      Meanwhile a request in LKML to enable to disable (sic!) all these mitigations was and met with an utter indifference and now if you want to reach previously available performance you have to peruse a ton of documentation and you also have to recompile the kernel since some mitigations are compiled-in regardless, without a runtime option to disable them.

      Well done, kernel devs, well done!

      Comment


      • #13
        Originally posted by Azrael5 View Post
        Is there a way to compensate this involution!?
        The unique way, would be to buy AMD..or run intel cpus without security, or even, run them with atom processors performance, but cost/consumption of top line processors..

        Comment


        • #14
          Originally posted by tuxd3v View Post

          The unique way, would be to buy AMD..or run intel cpus without security, or even, run them with atom processors performance, but cost/consumption of top line processors..
          AMD processors are immune?

          Comment


          • #15
            These kind of posts are the reason why I subscribed to Phoronix Premium. Thank you Michael, and keep up the great work!

            Comment


            • #16
              Originally posted by creative View Post
              schmidtbag Windows is fine. Been gaming on it for the past three weeks straight.
              sarcasm?

              Comment


              • #17
                OK, HyperThreading technology is now less hyper, but still does something

                Originally posted by oooverclocker View Post
                This is the biggest disaster for Intel CPUs with HT that I can imagine.
                I am only waiting someone to start exposing nVidia Ti cards vulnerabilities, that is the same crap - no one care about security there Or better to say - gamers does not care.
                Last edited by dungeon; 11-17-2018, 06:35 PM.

                Comment


                • #18
                  Originally posted by creative View Post
                  schmidtbag Windows is fine. Been gaming on it for the past three weeks straight.
                  Well depending on your display, GPU, and graphics settings, a performance loss up to 20% on the CPU might not be noticeable.

                  Comment


                  • #19
                    Originally posted by birdie View Post
                    Meanwhile a request in LKML to enable to disable (sic!) all these mitigations was and met with an utter indifference and now if you want to reach previously available performance you have to peruse a ton of documentation and you also have to recompile the kernel since some mitigations are compiled-in regardless, without a runtime option to disable them.

                    Well done, kernel devs, well done!
                    I find it interesting to note that "impact on kernel performance" was not considered/challenged by the person(s) replying to the original poster (Artem) in the thread.

                    Are Linux kernel developers not concerned with performance impacts of their coding?

                    I have fragments of memory that suggest that Linus has challenged contributors to justify/document the performance impact of their code, generally when those impacts were claimed to improve performance.

                    Some mitigations are included in CPU microcode according to Intel. The only way to revert that is to load older microcode.

                    A few kernel boot flags exist that will turn off some of these features. That is useful for testing and for those not interested in these fixes.

                    What bothers me is that the replies to the original poster (Artem) seemed to suggest that no kernel boot flags exist in some cases due to the use of GCC compiler flags. What are those flags? have they been clearly documented? I think GCC compiler flags being used to mitigate these security issues need to be clearly documented so those that want to "revert" those specific changes can do so by recompiling the kernel for themselves. Then a user can rebuild their kernel without any security fixes of their own choosing.

                    Seriously, it sounds to me like the responses in that email thread suggest Linux kernel devs simply accepting that these security fixes will negatively impact Linux kernel performance by taking a "let's not bring up that subject again" approach.

                    I say that Michael's testing is clearly("blatant" might be a better word) showing the "before & after" impact of these security fixes, especially in Intel processors.

                    It is times like this exact situation that prove the value of the work that Michael is doing.

                    Why the Linux Foundation or other large entities involved in Linux kernel development do not provide Michael and Phoronix with an annual grant to help defray his costs incurred in doing all of this performance testing is simply beyond me.

                    If the corporate world & Linux development communities can get something important like this testing for free, then why should they have to pay to support for it? Sad.
                    Last edited by NotMine999; 11-18-2018, 01:32 PM. Reason: fix a typo

                    Comment


                    • #20
                      Originally posted by NotMine999 View Post
                      Are Linux kernel developers not concerned with performance impacts of their coding?
                      Security goes above performance as performance is something relative

                      Not just about kernel, but about pretty much anything you have 3 base levels you can think of - secure, optimal or agressive. With less optimizations you are more safe and secure and the opposite

                      Goal is to be as optimal as possible (or just selective, so where really needed and where you expect an stronger impact), as not many like to run slow total secure crap

                      On this particular case, well users might like it or not but no doubt they must and should mitigate these, as these are hardware flaws
                      Last edited by dungeon; 11-17-2018, 07:21 PM.

                      Comment

                      Working...
                      X