Announcement

Collapse
No announcement yet.

Torvalds Blasts "Beyond Stupid" Flushing L1d On Context Switches - Reverts Code For Now

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

  • Torvalds Blasts "Beyond Stupid" Flushing L1d On Context Switches - Reverts Code For Now

    Phoronix: Torvalds Blasts "Beyond Stupid" Flushing L1d On Context Switches - Reverts Code For Now

    As part of the initial set of changes merged today for Linux 5.8 was the x86/mm material that included the controversial feature of opt-in flushing of the L1 data cache on context switching. Linus Torvalds ended up deciding to revert this functionality as for now at least he views it as crazy...

    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

  • #2
    Linus is the man !

    Comment


    • #3
      Shit! Linus didn't say shit or fuck even once in such a long post! He really did get brainwashed. Don't listen to him anymore, he's controlled by the alien brainwashers!

      Comment


      • #4
        Intel? Whats that?
        Should this L1d Flsuh help making Intel CPUs secure?
        Last edited by Pranos; 01 June 2020, 06:26 PM.

        Comment


        • #5
          Originally posted by Pranos View Post
          Intel? Whats that?
          They were a notable manufacturer of PC CPUs in the 80s, 90s, 2000s, and 2010s.

          Comment


          • #6
            While Linus certainly knows more about this kind of "deep" CPU stuff than me, this seems like a bit of an over reaction for something that will be optional.

            Comment


            • #7
              But what about wallets, encryption programs that must be very secure?
              Wouldn't this be helpful for those?

              Comment


              • #8
                Originally posted by Templar82 View Post
                While Linus certainly knows more about this kind of "deep" CPU stuff than me, this seems like a bit of an over reaction for something that will be optional.
                It being optional is a red herring.

                The fact that it got pushed shows that someone wanted it to be included.

                It's entirely possible that it would be sold to companies as a security feature, and upper managements everywhere would be all "turn it on, because we said so". Not really worth calling it a choice, at that point.

                If Linus's statements on performance check out, and I would suspect they are, it would be harmful to performance everywhere and would swamp countless developers with sudden bugtickets about bad performance, and tarnish Linux's reputation as a whole.

                Speculation or not, that's not a path I think anyone would want.

                Again, the point of "but it's optional" is a red herring. Who cares if it's optional? It will affect Linux as a whole.

                Comment


                • #9
                  Originally posted by Templar82 View Post
                  While Linus certainly knows more about this kind of "deep" CPU stuff than me, this seems like a bit of an over reaction for something that will be optional.
                  He may have let it go if he was convinced it would actually work. He raised questions on that especially when SMT is enabled.

                  Comment


                  • #10
                    Originally posted by Templar82 View Post
                    While Linus certainly knows more about this kind of "deep" CPU stuff than me, this seems like a bit of an over reaction for something that will be optional.

                    Not from what I read. It exposes a CPU scheduling and caching decision better left in kernel space and to admins to user space where any particular user can slip in a flag that enables L1D flushing whether the CPU errata specifies a need for it or not because $reasons. $reasons need not even be valid. On a multiuser system that's untenable. It appears to have not had a flag to disable it from ever being activated by admins if it's not useful or undesired. This means lazy and ignorant developers can drop that switch in on people "just in case, you know" on AMD or POWER users that aren't affected by the hardware bugs killing system performance for no valid stated reason.

                    How many projects have been listed on Phoronix alone areindiscriminately activating security features in CPUs that were later proven broken on some CPUs or generally incorrectly used? Of the top of my head I can think of three signature projects that did that: Gnome Desktop Manager, SystemD, and FreeBSD (RDRAND on the first two and FreeBSD for a while relied solely on hardware RNG that later turned out to have been purposely buggered for system entropy in Intel's case.) There's likely many others out there doing similar things that just haven't been noticed yet. There are far more developers out there than there are skilled eyes to audit that software.

                    There's also plenty of malware that would love to get their grubby hands on a user space switch that could slow an entire system to a crawl then demand ransom to "fix the problem". It doesn't even require a system breach. In university settings there's always some wit that wants to troll other students and faculty.

                    I felt Linus was pretty laid back about it all. The implementation left much to be desired, and there's no clear reason as yet been stated to need it in the state it'd been submitted.

                    Comment

                    Working...
                    X