Announcement

Collapse
No announcement yet.

Looking At The Linux Performance Two Years After Spectre / Meltdown Mitigations

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

  • #21
    birdie> 1. Too many websites are unusable without JS, even the phoronix forums. Question: How do we get evil websites to stop using javesecurityhole?

    Comment


    • #22
      Originally posted by tildearrow View Post
      Are you trying to turn this into LWN?
      The LWN subscription model seems like a pretty good one.

      Comment


      • #23
        No virtualization benchmarks? I remember virtualization was hit by 50% initially.

        Comment


        • #24
          Originally posted by xnor View Post
          Guys, Intel did not fix these defects by fixing the hardware design. That would have required a major redesign.
          Low-hanging fruits could have been fixed in actual hardware but the rest is just the same broken CPUs shipped with "fixes" (workarounds) in the firmware.
          CascadeLake hardware mitigations are noted here, and Intels products in general for software/hardware mitigation support can be seen here. You can also look at the security section of this article regarding Comet Lake, which I find a bit more readable to see what mitigations have what types of mitigation support. It's not complete as this phoronix article shows `mitigations=off` still having affect, so if you're curious what ones aren't covered that's a way to find out.

          Fixes/mitigations are that though. Don't see the issue you're raising other than perhaps potential performance improvement vs software/firmware fixes(which the Intel document I linked touches on briefly). You can definitely see them in effect with some of these benchmark results like ctx_clock(server variant), and the conclusion page performance% for Cascade Lake vs previous products without the hardware mitigations.

          It's not clear if there's notable overhead/cost with them being enforced in hardware without a way to disable like software ones, but the ctx_clock result suggests that it's unlikely? I'm not familiar with all these models to know how they compare to the Cascade Lake chips performance/spec wise if mitigations weren't a thing in it's hardware.

          Originally posted by MadCatX View Post
          Am I reading this wrong or are some of the hardware mitigations on the 10xxx series just as inefficient as the software ones except that you cannot switch them off? Nicely done.
          Originally posted by duby229 View Post
          Well if you look at the bar graphs some of those results show the newer chip with hardware mitigations performing much worse than the chips without hardware mitigations.

          Just look at some of the GEGL, GIMP, and OSbench results.... The software mitigations don't much affect that one chip, but that one chip is performing much worse than the comparable older chip. I'd even go so far as to say the hardware mitigations on the newer chip are impacting performance much worse than the software mitigations are on the comparable older chip.
          I don't know how the chips compare specs/performance wise, but Cascade Lake is multi-chip, similar to Ryzen models where one CPU can have multiple NUMA nodes, there's clearly hardware differences there beyond the mitigations, so if anything is actually comparable to it there, you're making assumptions with those benchmarks since they're not exactly apples to apples when other factors like NUMA nodes can affect the results. Not particularly interested investing the time to look at the other models and their hardware specs vs Cascade Lake and how the differences can impact results differently beyond hardware mitigations.

          Without keeping such in mind. It's difficult to know how much of an impact these hardware mitigations have vs if they were possible to disable. ctx_clock at least shows rather clearly that mitigations there are efficient vs software.

          [QUOTE=MadCatX;n1152178]
          Robbing the user of the opportunity to get some performance back by switching the mitigations off seems rather idiotic./QUOTE]

          Probably more difficult to provide on a hardware level...? I mean, you might as well spin that the other way, and ask AMD to make their hardware vulnerable for enabling better performance too, since afaik AMD is praised for not having the vulnerabilities, and that Intel has them from taking short-cuts/cheating for performance wins at the cost of security. So AMD is also robbing users of such an opportunity? I don't think people see it that way :P

          Comment


          • #25
            Rust never sleeps. Apparently, neither does Michael. :-)

            A friend and I were recently discussing this and the net impact on the vast (Linux/FOSS) machine infrastructure of the Internet. Staggering. He speculated that at the rate vulnerabilities are discovered, we could lose net an entire generation of processor performance gains.

            Michael, keep up the great work! I look forward to your reporting and benchmarks every day! (Do put your feet up now and again, ok?)
            Last edited by junkbustr; 01-14-2020, 02:36 AM.

            Comment


            • #26
              Originally posted by nomadewolf View Post

              Are you sure that HW mitigations have the exact same impact as SW mitigations?
              And, why?
              HW is not magic, if you have to clear a certain cache in a particular way to avoid the mitigation it does not matter much if that clear cmd is done in the cpu microcode or if it's done in SW. Yes it could be done slightly faster in some cases in HW but one advantage that SW have over HW is that the SW can choose when and where to apply the mitigation while the HW have to apply it everywhere so we can e.g implement certain things only where it matters (inside the kernel) and ignore it in say userspace where it does not matter (depends upon the mitigation of course).

              A new architecture that is built from scratch to avoid this family of vulnerabilities will take several years to develop and even then it's very likely that those CPUs will be slower than todays CPUs clock for clock (and thus perhaps never even released). There might just not be any way that you can perform speculative execution safely and if you completely disable that performance will go down the drain.

              Comment


              • #27
                Which is the incidence over AMD Cpus? thanks

                Comment


                • #28
                  Originally posted by xnor View Post
                  Guys, Intel did not fix these defects by fixing the hardware design. That would have required a major redesign.
                  Low-hanging fruits could have been fixed in actual hardware but the rest is just the same broken CPUs shipped with "fixes" (workarounds) in the firmware.
                  The best fix is to punish Intel switching to AMD as I have done. I know AMD has its own flaws but it has been less guilty and less involved than Intel.

                  Comment


                  • #29
                    I like the brown and gray, stands out from the background and is easy on the eyes.

                    Comment


                    • #30
                      Originally posted by duby229 View Post

                      Well if you look at the bar graphs some of those results show the newer chip with hardware mitigations performing much worse than the chips without hardware mitigations. Even though the software mitigations don't much affect the result, the result is that some of those results for chips with hardware mitigations much worse than the chips without hardware mitigations even when using the software mitigations.

                      Just look at some of the GEGL, GIMP, and OSbench results.... The software mitigations don't much affect that one chip, but that one chip is performing much worse than the comparable older chip. I'd even go so far as to say the hardware mitigations on the newer chip are impacting performance much worse than the software mitigations are on the comparable older chip.
                      Couldn't Intel be just doing software mitigations via firmware on the new chips?

                      Comment

                      Working...
                      X