“As for why the Ryzen 7000 series performance is actually slower if disabling the Spectre V2 mitigations, that's likely something only AMD can effectively answer but presumably…”<p><i>Just ask!</i><p>Seriously. You can ask AMD. Maybe they won’t tell you, but <i>they might</i>. It might be really good info. Why not ask someone who is really knowledgeable about this stuff like a kernel developer who works on x86-64 or worked on the mitigations?<p>This is what I never understand about Phoronix. People link to them all the time but they run a bunch of benchmarks and then end on “there you go”. I’d like investigation into <i>why</i>. You won’t always get an answer but you should try.
An interesting comment made in the Phoronix forums:<p>> My theory is that fixing the Spectre V2 vulnerability on a hardware level would lead to fundamental architecture changes that AMD is not willing to make, because it may add so much more complexity to the architecture or it may just be too unconvenient. They probably realized that optimizing the code paths that the Linux kernel utilizes on the default mitigations mode is faster, simpler and it may involve less deeper changes, while still being secure.<p>> As far as I know, pretty much every CPU architecture that implements speculative execution is vulnerable to some version of Spectre, so note that this is not a fundametal flaw of AMD64.
This is basically just saying: the super clever AMD designers and Linux kernel developers have optimised for the setting they recomend and most people use. An insecure setting they recomend against isn't yet well optimised on brand new hardware.
meh, maybe they just flush TLB every time in hardware level if you disabled the mitigations, ane disabled the hardware flush if the software side can handle it
Interesting. I wonder if the kpti path leveraging PCID has 'tipped' into a performance improvement? Maybe a larger PCID cache on the CPUs and optimized codepaths for specter-usage?