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

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

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

    Last week marked the two year anniversary since the formal public disclosure of the Spectre and Meltdown disclosures. To commemorate that anniversary, I was running some fresh benchmarks of various Intel desktop and server processors with the in-development Ubuntu 20.04 LTS to look at the performance impact today with the default CPU vulnerability mitigations and then again with the mitigations disabled at run-time.

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

  • hotaru
    replied
    Originally posted by ndegruchy View Post
    I know AMD is affected to some degree, I'm not sure if ARM-based chips were hit.
    out-of-order ARM chips (A72, A75, A76, etc) were hit about the same as AMD. in-order ones (A53, A55, etc) aren't affected, but are obviously much slower. right now the best way to go looks like ARM for low power stuff and AMD for everything else.

    Leave a comment:


  • ndegruchy
    replied
    Glad to see that it's not entirely a dumpster fire for Intel (especially servers). Still, the fact that this happened and was known for nearly a decade really sours me on Intel. New devices I am buying will have AMD or ARM CPUs in them. I know AMD is affected to some degree, I'm not sure if ARM-based chips were hit. Hopefully this issue was a shot across the bow of future manufacturers.

    Probably not, though. We'll get the same trash with a different package and a promise that things are all better now (read: different problem, same scale).

    Leave a comment:


  • duby229
    replied
    Originally posted by nomadewolf View Post

    Couldn't Intel be just doing software mitigations via firmware on the new chips?
    yeah, I'm sure they must be

    Leave a comment:


  • nomadewolf
    replied
    Originally posted by F.Ultra View Post

    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.
    Wow. This is a great explanation.
    Yes, if in fact cache has to be cleared, that means a huge impact on performance.
    Makes sense.

    Leave a comment:


  • nomadewolf
    replied
    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?

    Leave a comment:


  • Mike Frett
    replied
    I like the brown and gray, stands out from the background and is easy on the eyes.

    Leave a comment:


  • Azrael5
    replied
    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.

    Leave a comment:


  • Azrael5
    replied
    Which is the incidence over AMD Cpus? thanks

    Leave a comment:


  • F.Ultra
    replied
    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.

    Leave a comment:

Working...
X