The Spectre Mitigation Performance Impact On AMD Ryzen 5000 "Zen 3" Processors

For those wondering what the current cost is to the default Spectre mitigation protections on the new AMD Ryzen 5000 series "Zen 3" processors, here are a set of performance tests looking at that overhead with the still relevant mitigations applied by default and then if forcing them off. The Zen 3 mitigation overhead was compared then to similar AMD Zen 2 and Zen+ processors.

After looking last week at the odd state of mitigation performance on Intel's new Tiger Lake processors, the attention shifted to looking at the mitigation overhead for the new AMD Zen 3 processors. Thankfully there is less mitigations to worry about with AMD processors but still even with these new processors there is still a measurable difference in affected workloads between mitigations on and off. Also, unlike Tiger Lake and contrary to rumors, the Zen 3 mitigation performance was in the right direction: disabling the mitigations did help boost the performance as is logical, unlike what we saw with Tiger Lake where now disabling the mitigations hurt the overall performance.

Tested this round were the AMD Ryzen 5 2600X, Ryzen 5 3600XT, and Ryzen 5 5600X processors with the out-of-the-box/default security mitigations on the Linux 5.9 stable kernel and then re-testing the processors with the "mitigations=off" flag to disable the run-time controlled mitigation settings.

When it comes to mitigation differences with Zen 3, the CPUs still are mitigating Spectre Variant Four "Speculative Store Bypass" with SSB disabling via PRCTL and SECCOMP, Spectre Variant One via usercopy/SWAPGS barriers and __user pointer sanitization, and then Spectre Variant Two is where there is a difference with Zen 3. Spectre V2 mitigations on Zen 3 is still using the full AMD retpoline "return trampolines", conditional IBPB (Indirect Branch Prediction Barrier is conditional on SECCOMP or indirect branch restricted tasks), RSB (Return Stack Buffer) filling enabled, and then for the Single-Threaded Indirect Branch Predictors (STIBP) the difference compared to Zen 2 is now the always-on preferred mode.

That appears to be the main change with Zen 3 from the Spectre mitigation angle is that for STIBP handling is now made always-on rather than conditional. Even for the Ryzen 5 3600XT with the latest CPU microcode it's still on conditional STIBP where as Zen 3 is using always-on. The always-on mode uses STIBP on all tasks where as conditional uses it on SECCOMP processes or indirect branch restricted tasks. STIBP is used for preventing a sibling thread of a core from controlling/influencing the predictions of the other thread.

Then again, back when AMD Zen 2 first launched we noted that AMD now defaulted to always-on STIBP. That later changed with a BIOS/microcode update. So at this point it remains to be seen if the always-on STIBP is intentional with Zen 3 or something that may change with a later CPU microcode update. I have checked with other Zen 3 CPUs and on other motherboards as well, with these new CPUs it does seem to be always-on STIBP as the default.

The AMD Ryzen 5 2600X / 3600XT / 5600X were tested on the same system using Ubuntu 20.10 with the Linux 5.9.10 kernel. A variety of benchmarks were carried out known to be relevant to the various CPU security mitigations with the Phoronix Test Suite.