A week ago, news about AMD's Inception vulnerability broke, and the first deep dive into the performance impact of mitigations has been published. Linux-centric Phoronix has just uploaded eight pages of test results. Using an AMD Epyc 7763 (Zen 3) based system, running Linux (of course), the site tested a plethora of apps and tabulated before and after-patching results. Depending on workload, you might not see much difference — however, some tasks were up to 54% slower on a patched system.
For the above table we looked at some of the worst results, as well as some of the test results from more-familiar apps like 7zip, Blender, and Firefox. Those three familiar apps don't suffer too much from the AMD Inception mitigations. Of the three, compression app 7zip seems to be the most affected — but how long do you spend de-compressing files in an average day?
Much more serious performance consequences are observed in applications that work on databases, code compilation, engineering, and image processing. The worst result we saw, with MariaDB, shows database operations were severely impacted on a patched Epyc system.
(Image credit: Phoronix)
If you head over to Phoronix for a closer look at the data and a wider selection of results you will see that the results sometimes show more than just the AMD Inception mitigation being 'off' or 'on'. There will be up to three levels of patching with different configurations — some with purely kernel-based mitigations, others with the newest microcode, and another with the most secure Indirect Branch Prediction Barrier (IBPB) mitigation. Please note that IBPB was frequently (but not always) shown to be the worst performer of all mitigations. The default AMD Linux mitigation is 'safe RET mode'.
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
Mark Tyson is a news editor at Tom's Hardware. He enjoys covering the full breadth of PC tech; from business and semiconductor design to products approaching the edge of reason.
No mention of the significant performance increases between the two tests? That seems very weird.
The '-xx%' values are where rates (something per second) have decreased, a performance decrease.
The '+xx%' values are where time has increased (seconds taken to do something), also a performance decrease.
Also note that the MariaDB 11 / 4096 clients on IBPB is the big outlier : using safe RET with firmware is a smaller hit, and other DB benches showed far less of an impact. More than likely, a piece of MariaDB code does something that triggers huge number of branch jumping, triggering a lot of overhead, and that may be fixed in a future release - I wouldn't be surprised if Intel's latest mitigation didn't cause similar performance lisses.
The penalty seems very workload dependent and averages a lot less than 54%.
It seems like it hurts I/O performance a bit like the early spectre fix, which was bad for some games with my large cache 5775c. I have no way of knowing if something similar will happen with the X3D, but I'd look for it to maybe happen with some games that favor that chip over the similar one with regular cache if and when gaming benchmarks for these mitigations come out.
Personally I turned off that spectre mitigation for gaming. Not that these current mitigations should be off for servers, but if you are the only one you are knowingly putting at risk it is your chip, your choice.
I guess the biggest takeaway is that clouds will get partitioned into more expensive and riskier, driving up overall cost, as these mitigations most likely cannot be enabled at a VM level.
If you don't share you hardware with any workload you cannot control, it may be well worth considering to disable the mitigations.
I'd also love to see those researchers have a go at the hyperscaler ARM chips to see if they do better.
Also note that the MariaDB 11 / 4096 clients on IBPB is the big outlier : using safe RET with firmware is a smaller hit, and other DB benches showed far less of an impact. More than likely, a piece of MariaDB code does something that triggers huge number of branch jumping, triggering a lot of overhead, and that may be fixed in a future release - I wouldn't be surprised if Intel's latest mitigation didn't cause similar performance lisses.
I would like to see them benchmark these same software six months from now, with all updates applied. It's possible that a workaround can be done at the software level, and some of that performance loss is mitigated. I mean, MariaDB developers won't just sit still when a firmware cuts half of its performance, right?
If there was ever a reason to upgrade a socketed CPU, this may be it. It could be a win-win for both AMD and the customer. The same applies to Intel. (no, it won't be free or be covered by a class action suit if there is any sanity in this world.). New CPU would be inherently faster and would have all known hardware issues fixed.
If there was ever a reason to upgrade a socketed CPU, this may be it. It could be a win-win for both AMD and the customer. The same applies to Intel. (no, it won't be free or be covered by a class action suit if there is any sanity in this world.). New CPU would be inherently faster and would have all known hardware issues fixed.
Sorry, but that's naive and wishfull thinking.
The CPUs are exploitable because they cut corners in search for speed. Not cutting corners will cost speed, even if a little less when done properly in hardware.
Unlike in the FDIV case, nobody ever guaranteed that CPUs cannot be exploited via side-channel attacks. All code executes as described in the instruction set manuals. So I don't see any chance for a class action suit to succeed, especially if most people won't be personally affected.
And as you said: news CPUs can only ever fix the known issues, because protecting against out-of-order side channels, requires an in-order architecture and few people want to go back to that speed.
There might be an opportunity for vendors to support in-order "S-cores" for such security critical code, but given the track record for all current hardware security support blocks, I'm not optimistic and would probably prefer a PCIe card (or even an USB-stick) for that, which can be replaced much easier.
Such a design that might even be formally verified on its hardware description language to contain no potential for speculative exploitation, might get the vendor attestation you'd need for a class action suit if it fails anyway. Until then it's much like demanding that your car shan't kill you or anyone even if you're drunk or just not paying attention.
