Announcement

Collapse
No announcement yet.

An Early Look At The L1 Terminal Fault "L1TF" Performance Impact On Virtual Machines

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

  • An Early Look At The L1 Terminal Fault "L1TF" Performance Impact On Virtual Machines

    Phoronix: An Early Look At The L1 Terminal Fault "L1TF" Performance Impact On Virtual Machines

    Yesterday the latest speculative execution vulnerability was disclosed that was akin to Meltdown and is dubbed the L1 Terminal Fault, or "L1TF" for short. Here are some very early benchmarks of the performance impact of the L1TF mitigation on the Linux virtual machine performance when testing the various levels of mitigation as well as the unpatched system performance prior to this vulnerability coming to light.

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

  • #2
    thanks for the testing michael , i think your coverage of all this speculative execution issues has gained phoronix some deserved attention

    Comment


    • #3
      Well, overall it seems better than meltdown... But testing with just one VM may not say much.

      Still haven't personally seen technical details on the mitigation yet...

      Anyway, great work here. Especially so soon after the embargo was lifted.

      Comment


      • #4
        So, if I'm hosting "potentially insecure" VMs, I need to enable full. Which would mean, if I'm using intel processors on, say, AWS...I'm taking an absolutely disastrous performance hit? Am I reading that right?

        Comment


        • #5
          Originally posted by Sloth View Post
          So, if I'm hosting "potentially insecure" VMs, I need to enable full. Which would mean, if I'm using intel processors on, say, AWS...I'm taking an absolutely disastrous performance hit? Am I reading that right?
          I don't think Amazon or other public clouds have communicated their complete mitigation yet... but I imagine they will just be ensuring that sibling threads (core+HT) are bound to the same VM by their scheduler to avoid potential implications of thread/core sharing between VMs rather than just disabling SMT/HT given it would cost them a lot otherwise.
          Michael Larabel
          http://www.michaellarabel.com/

          Comment


          • #6
            Do you plan on doing a comprehensive performance impact test of all known Meltdown/Spectre mitigations? With multiple known exploits, would be interesting to see how a completely unpatched system peforms vs systems that patch all known Meltdown/Spectre exploits.

            Comment


            • #7
              Originally posted by gururise View Post
              Do you plan on doing a comprehensive performance impact test of all known Meltdown/Spectre mitigations? With multiple known exploits, would be interesting to see how a completely unpatched system peforms vs systems that patch all known Meltdown/Spectre exploits.
              Yes planning to after 4.19 calms down post-merge-window and if any other L1TF patches come about.
              Michael Larabel
              http://www.michaellarabel.com/

              Comment


              • #8
                Originally posted by davidbepo View Post
                thanks for the testing michael , i think your coverage of all this speculative execution issues has gained phoronix some deserved attention
                Not to mention Phoronix was the go-to for proper Threadripper performance benches. Bunch of HN and Reddit comments addressed the pathetic Windows-based benchmarks that all the youtubers et al were doing, including, unforgivably, Anandtech, by pointing to Phoronix.

                Comment


                • #9
                  Originally posted by Sloth View Post
                  So, if I'm hosting "potentially insecure" VMs, I need to enable full. Which would mean, if I'm using intel processors on, say, AWS...I'm taking an absolutely disastrous performance hit? Am I reading that right?
                  That remains to be seen, I believe Amazon is probably a member of the exclusive club that gets to implement fixes early, with many instance types you already get dedicated hyperthreads which could easily be bound to your VM. It may very well be a problem with the burstable types (t2.*).

                  Comment


                  • #10
                    Almost seems like when Linus spat the dummy because "It seems like Intel doesn't feel like properly fixing their shit", that he sensed correctly that Intel still had lots of stuff they knew was going to stink.

                    Comment

                    Working...
                    X