AMD Zen 1 Linux Performance Hit From Retbleed, Accumulated CPU Mitigation Impact

[phoronix]

Phoronix: AMD Zen 1 Linux Performance Hit From Retbleed, Accumulated CPU Mitigation Impact

Last week I posted my initial benchmarks for the Linux impact of mitigating Retbleed as the newest CPU speculative execution vulnerability. As noted in the prior Retbleed articles, on the AMD side it's Zen 1/1+/2 processors affected as well as older Bulldozer CPUs. That earlier article included Zen 2 benchmarks while in this article are Zen 1 tests given its situation is slightly different.

https://www.phoronix.com/scan.php?page=article&item=amd-zen1-retbleed&num=1

[Guest]

When disabling SMT on my 2700X + X470 board, my NVMe SSD gets assigned only 9 IRQs. With SMT on, I get 17 IRQs for it. Does anyone know why this happens? Also I wonder if the kernel option to disable SMT/HT changes the behavior of this?

[schmidtbag]

When disabling SMT on my 2700X + X470 board, my NVMe SSD gets assigned only 9 IRQs. With SMT on, I get 17 IRQs for it. Does anyone know why this happens? Also I wonder if the kernel option to disable SMT/HT changes the behavior of this?

Just a guess:
That's an 8 IRQ difference and 8 fewer threads. For AMD, their SMT method is almost another whole core (hence the FX 8150 being advertised as an 8-core). It makes sense that each "core"/module would have its own ability to be interrupted.

[aufkrawall]

Imagine the stupid expressions on faces that once cheered when Intel was hit by first sidechannel attack demonstrations.

[birdie]

Overall a pretty horrible showing from Zen 1. Looks like with the current mitigations it's not much better than the Intel uArchs affected by the meltdown fiasco.

[birdie]

When disabling SMT on my 2700X + X470 board, my NVMe SSD gets assigned only 9 IRQs. With SMT on, I get 17 IRQs for it. Does anyone know why this happens? Also I wonder if the kernel option to disable SMT/HT changes the behavior of this?

Does it affect NVME IO performance? If not, why bother?

[Melcar]

I still have a 1700 in a box somewhere. Was planning to get a cheap B450M and make a nice small backup PC but with all these performance penalties form modern mitigations it may not be worth it. Can't use W11 with it and can't use latest Linux distros. The days of being able to keep 5+ year old hardware perfectly serviceable are about to end it seems.

[birdie]

I still have a 1700 in a box somewhere. Was planning to get a cheap B450M and make a nice small backup PC but with all these performance penalties form modern mitigations it may not be worth it. Can't use W11 with it and can't use latest Linux distros. The days of being able to keep 5+ year old hardware perfectly serviceable are about to end it seems.

Backup PC? or a PC for backups? For the latter these mitigations mean basically nothing. For the former you could always run with `mitigations=off` - more than four years after the attacks disclosure we still have no malware in the wild using them. These vulnerabilities are criticial for cloud providers and people running [malware in] VMs, not for end users.

[Vistaus]

Imagine the stupid expressions on faces that once cheered when Intel was hit by first sidechannel attack demonstrations.

Right? I love my AMD Ryzen 9, but AMD isn't perfect and I hope more people will see that now. Both Intel *and* AMD need to step up their game and fix this mess.

[waxhead]

Michael: did you try without microcode patches as well? As I mentioned in a much older thread somewhere: mitigations off might not be particularly faster if the problem is still being worked around in microcode. It would be interesting to see the difference with and without microcode patches applied.