Announcement

Collapse
No announcement yet.

A Look At The MDS Cost On Xeon, EPYC & Xeon Total Impact Of Affected CPU Vulnerabilities

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

  • A Look At The MDS Cost On Xeon, EPYC & Xeon Total Impact Of Affected CPU Vulnerabilities

    Phoronix: A Look At The MDS Cost On Xeon, EPYC & Xeon Total Impact Of Affected CPU Vulnerabilities

    This weekend I posted a number of benchmarks looking at the performance impact of the new MDS/Zombieload vulnerabilities that also included a look at the overall cost of Spectre/Meltdown/L1TF/MDS on Intel desktop CPUs and AMD CPUs (Spectre). In this article are similar benchmarks but turning the attention now to Intel Xeon hardware and also comparing those total mitigation costs against AMD EPYC with its Spectre mitigations.

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

  • #2
    Typo?

    Originally posted by phoronix View Post
    out-of-the-box CPU mitigations applied currently by the Linux kernel respectively for Intel and AMD) / mitigations=auto,sosmt (disabling SMT / Hyper Threading where deemed unsafe, Cascadelake didn't see HT disabled in this configuration and obviously not relevant for AMD)

    Comment


    • #3
      Originally posted by tildearrow View Post
      Typo?
      Nah. Summarizes the technology. So-so-SMT.

      Comment


      • #4
        I'm getting a feeling that this thread will be full of AMD shills pretty soon.

        Oh well, cascadelake looks pretty good right now, but who knows what will happen after a couple more vulnerabilities roll out together with their mitigations.

        Comment


        • #5
          As opposed to the delusional making excuses for Intel?

          Originally posted by DoMiNeLa10 View Post
          I'm getting a feeling that this thread will be full of AMD shills pretty soon.
          Well AMD or not this testing highlights a real problem and in some instance less I can see users having to replace relatively new servers. Pointing out that AMD appears to be delivering more stable hardware for the data center isn’t being a shill, it just reflects a change in the marketplace.
          Oh well, cascadelake looks pretty good right now, but who knows what will happen after a couple more vulnerabilities roll out together with their mitigations.
          I think what will happen is pretty clear, more hardware will be considered that isn’t Intel based. Obviously the intended usage is a factor in server selection, however Intel’s failures highlight the dangers of Homogeneous installations. So yeah hopefully more AMD hardware gets installed along with more Power and ARM based hardware.

          To put it another way Intels screw ups are good for competition. Hopefully we will get a few people in the corporate world reconsidering the stupidity of throwing all their money at Intel. Ive never understood why Intel gets a pass every time they screw up.

          Comment


          • #6
            Originally posted by DoMiNeLa10 View Post
            I'm getting a feeling that this thread will be full of AMD shills pretty soon.
            And with that comment you point out that the Intel shills are already here.

            Can't this analysis be done objectively, keeping to the facts and without resorting to calling anyone you don't agree with a shill? Pointing out that AMD is doing better in a certain area isn't shilling; it's simply stating what is being proven to be a fact.

            Comment


            • #7
              Ouch, these hits on everything below Cascadelake are quite significant. That is a regression of nearly two generations of Intel's CPU performance improvements. And AMD's Rome is just around the corner, the hits seem to come right at the time where Intel appears to be very weak and vulnerable. Furthermore, their lineup for fighting Zen 2 and 3 doesn't seem to be compelling for the broader market, the hardware mitigations are becoming their biggest selling point and I wonder what their customers might think of this. If I were one of them (milked over the last ten years as their cash cow), I'd show them the door and walk to the competition.

              Comment


              • #8
                Originally posted by phoronix View Post
                PostMark mostly exercises fsync and for this testing the EPYC server saw a 3.5% hit from its relevant Spectre mitigations while the Xeon Platinum 8280 saw a 4% performance hit from its relevant mitigations. The Xeon Gold 6138 server was most impacted with a 18% hit to the performance due to not seeing any hardware mitigations unlike the brand new Cascadelake processors.
                Originally posted by phoronix View Post
                PostgreSQL is one of the server workloads being affected a lot by Spectre/Meltdown/Zombieload and especially so if disabling HT/SMT. In this particular run, the Xeon Gold 6138 server had been outperforming the EPYC 7601 2P server unmitigated but once mitigated fell behind the AMD server being tested.
                Are the numbers between AMD and Intel even comparable here? If I understand correctly, the systems use different storage:
                AMD uses "120GB SSDSCKJB120G7R + 20 x 500GB Samsung SSD 860" while Intel uses "Samsung SSD 970 PRO 512GB" according to the table

                Comment


                • #9
                  Ahh.. Intel will be fine.

                  I look at it this way. The next root kit will install 20% slower. Bonus!

                  Comment


                  • #10
                    Why use Cascade Lake CPUs with hardware mitigations? The Skylake Xeons aren´t hit that hard by the mitigations either.. Furthermore some of the benchmarks are far from realworld workloads.. For example Sockperf, it just saturates the network link, most load is inside the kernel without context switchting..

                    The Postgres Benchmark is the only relevant IMHO..
                    Where are the nginx, apache or Maria DB benchmarks?
                    Where are the Hypervisor Benchmarks? A lot of enterprises run ESXi Clusters to virtualize their servers.

                    Furthermore a lot of existing enterprise server hardware is still Haswell / Broadwell based..
                    For example Google Cloud compute still has active clusters with Sandy Bridge CPUs: https://cloud.google.com/compute/docs/cpu-platforms

                    Comment

                    Working...
                    X