Announcement

Collapse
No announcement yet.

Zombieload V2 TAA Performance Impact Benchmarks On Cascade Lake

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

  • Zombieload V2 TAA Performance Impact Benchmarks On Cascade Lake

    Phoronix: Zombieload V2 TAA Performance Impact Benchmarks On Cascade Lake

    While this week we have posted a number of benchmarks on the JCC Erratum and its CPU microcode workaround that introduces new possible performance hits, also being announced this week as part of Intel's security disclosures was "Zombieload Variant Two" as the TSX Async Abort vulnerability that received same-day Linux kernel mitigations. I've been benchmarking the TAA mitigations to the Linux kernel since the moment they hit the public Git tree and here are those initial benchmark results on an Intel Cascade Lake server.

    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
    So there is only one benchmark where TSX with mitigations is now faster than disabling TSX. That is SVT-VP9 0.1, and it is margin-of-error kind of difference (252 vs 250 FPS). As far as I know, the reason for this feature to exist was to improve performance. Now it seems to do the opposite.

    These Intel speculative execution bugs are a gift that just keeps on giving! Not even to mention that the Intel's first implementation of TSX was buggy beyond being fixable by microcode, and it was simply disabled via a microcode update.

    Comment


    • #3
      Originally posted by fintux View Post
      So there is only one benchmark where TSX with mitigations is now faster than disabling TSX. That is SVT-VP9 0.1, and it is margin-of-error kind of difference (252 vs 250 FPS). As far as I know, the reason for this feature to exist was to improve performance. Now it seems to do the opposite.

      These Intel speculative execution bugs are a gift that just keeps on giving! Not even to mention that the Intel's first implementation of TSX was buggy beyond being fixable by microcode, and it was simply disabled via a microcode update.
      The only real question here is if the kernel developers are aware that is possible for the next 14nm+++++++++++++++++++ Intel CPU family to trigger buffer overflows on /proc ??

      i mean jesus, this is from Haswell and is not even updated yet to show the last 2 or 3 in the latest point releases.

      bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs

      i guess for the next gen I9 you will have to cat cpuinfo and cpuinfo/bugs separately LOL

      Comment


      • #4
        It will be interesting to test the cumulative effect of all the mitigations intel's cpus were subject to the last couple of years. All on vs all off.

        Comment


        • #5
          Originally posted by ddriver View Post
          It will be interesting to test the cumulative effect of all the mitigations intel's cpus were subject to the last couple of years. All on vs all off.
          I guess they'll end up on Bulldozer performance or something. The same level that all sorts of people blamed AMD for having. Seems intel only won the past race due to driving without helmet, seat belt, safety goggles or brakes. ;-)
          Ah, well. Back to enjoying my relatively error free AMDs and elderly in-order-chips.

          Don't anyone get me wrong: mistakes happen. But what intel delivers here is close to being on purpose and same level as certain car manufacturers with their exhaust gas cheatery.
          Stop TCPA, stupid software patents and corrupt politicians!

          Comment


          • #6
            Originally posted by jrch2k8 View Post

            bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs

            i guess for the next gen I9 you will have to cat cpuinfo and cpuinfo/bugs separately LOL
            Heh, and once you update your kernel to 5.3.11 or newer, your bug list will have to scooch over to make room for a new guy:

            bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit

            On the plus side, our Haswell's never got shipped with TSX so we're unaffected by TSX async abort!

            -Sent from my i5-4670K

            Comment


            • #7
              Drink!

              Comment


              • #8
                Originally posted by perpetually high View Post

                Heh, and once you update your kernel to 5.3.11 or newer, your bug list will have to scooch over to make room for a new guy:

                bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit

                On the plus side, our Haswell's never got shipped with TSX so we're unaffected by TSX async abort!

                -Sent from my i5-4670K
                If I remember correctly Haswell did ship with TSX, but it was buggy so Intel disabled it. Broadwell also shipped with TSX, but it was buggy, so Intel disabled it..

                Turns out third time wasn't the charm, it just took longer to realise it was still buggy.

                Comment


                • #9
                  Originally posted by Adarion View Post
                  I guess they'll end up on Bulldozer performance or something. The same level that all sorts of people blamed AMD for having. Seems intel only won the past race due to driving without helmet, seat belt, safety goggles or brakes. ;-)
                  I like that analogy.
                  About a year ago, I was wondering how different the Bulldozer-era benchmarks would've been received if Intel's products were properly secured. As far as I'm concerned, it still would've fared worse, but, perhaps the margins would've closed up enough where we may have seen AM3+ Excavator chips, or perhaps AMD wouldn't have bothered with the FX-9000 series.

                  Comment


                  • #10
                    Originally posted by jrch2k8 View Post

                    The only real question here is if the kernel developers are aware that is possible for the next 14nm+++++++++++++++++++ Intel CPU family to trigger buffer overflows on /proc ??

                    i mean jesus, this is from Haswell and is not even updated yet to show the last 2 or 3 in the latest point releases.

                    bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs

                    i guess for the next gen I9 you will have to cat cpuinfo and cpuinfo/bugs separately LOL
                    All these pluses refer to bugs they've just added to their design. It feels like they add a couple of more vulns with every "fix" in hardware they provide.

                    Comment

                    Working...
                    X