Announcement

Collapse
No announcement yet.

Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

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

  • #21
    Not a hard guess to make really.
    I've been nagging about this crap security fiat mentality and whilst every speculation type mitigation goes into core kernel/arch stuff.
    I hate when broken hardware make it that deep into core for "bugfixing".
    Broken is broken. Hardware or software. I wish for some Linus middle fingers right now.
    "FU Intel"

    Comment


    • #22
      This is really great work Michael and I wish I had some money to throw at you right now to support it.

      Comment


      • #23
        I told you so :-/

        Comment


        • #24
          Originally posted by perpetually high View Post

          I see, thanks for clearing that up.
          as michael loves news stories, maybe worth the ad review to push an article mentioning Intel's statement?

          Comment


          • #25
            Once again...why exactly do threads WITHIN a process need to be protected from each other? ermo pointed out in another thread that the Microsoft kernel's mitigation for these hyperthreading security problems only applies between threads belonging to different processes running on the same physical core. Why not implement this in Linux? Is it because everyone is looking at benchmarks that spawn a bunch of processes?

            Comment


            • #26
              I guess now we know that Intel was outperforming AMD by cheating.

              Comment


              • #27
                Originally posted by campbell View Post
                Once again...why exactly do threads WITHIN a process need to be protected from each other? ermo pointed out in another thread that the Microsoft kernel's mitigation for these hyperthreading security problems only applies between threads belonging to different processes running on the same physical core. Why not implement this in Linux? Is it because everyone is looking at benchmarks that spawn a bunch of processes?
                Well, not all browser tabs run in different processes. Theoretically tabs from different domains might be running JavaScript in the same process, and there are known ways to exploit Spectre et al from JavaScript. Virtual machines might also be susceptible if they run the guest in the same process. etc etc
                Last edited by amehaye; 11-16-2018, 05:20 PM. Reason: typo

                Comment


                • #28
                  Originally posted by campbell View Post
                  Once again...why exactly do threads WITHIN a process need to be protected from each other? ermo pointed out in another thread that the Microsoft kernel's mitigation for these hyperthreading security problems only applies between threads belonging to different processes running on the same physical core. Why not implement this in Linux? Is it because everyone is looking at benchmarks that spawn a bunch of processes?
                  There are edge cases like KVM where each virtual core is a separate thread within the same process. The threads could be running different privilege level processes and the host thread scheduler would have no clue. This is not a one off case either. This could be true with any machine emulator, including ones that do not use KVM. There really is no generic way for the kernel to be able to tell.

                  Comment


                  • #29
                    Seven more speculative execution vulnerabilities found. An absolute disaster for CPU design. I guess the answer is remove Hyper Threading from mainstream processors and bump up the core count and remove speculative decision making from the architecture and offset the losses with clock speed increases. 7 to 8 GHz would be good? I guess smarter and more efficient processor design means worse security.

                    Comment


                    • #30
                      Originally posted by ms178 View Post
                      2018 turns out to be a very bad year for Intel CPU owners (especially pre-Haswell, myself included). And there is still more research on the way which might lead to even worse performance. My god, they should be forced to sell their CPUs with red warning stickers only...
                      Why pre-Haswell? Intel decided to to avoid developing fixes for anything older than Sandy Bridge.

                      https://arstechnica.com/gadgets/2018...ancient-chips/

                      i would think it would be worse for anything pre-Sandy Bridge.

                      Comment

                      Working...
                      X