Yeah the next gen threadrippers are a big question mark right now, it sounds like they are going to come in two completely different sockets (SP5 and SP6) depending on if it is workstation or HEDT; also the word on the street is that both different flavors of threadripper are going to have some of their memory channels disabled so as to not compete with EPYC, 2 channels disabled on HEDT and 4 channels disabled on workstation.
The workstation threadripper 7000 with 4 disabled memory channels could at best match xeon w3400 in memory performance, but would likely be slower.
For non-memory bound problems AMD will likely be faster though assuming they can figure out how to patch their Inception vulnerability without the current mitigation’s performance hits.
Well the microcode updates for servers is already here.
The microcode updates for consumers boards and cpus should arrive sometime around the end of year if the board vendors can get it together in a AGESA update.
You can then remove the kernel command line bypass.
Does spec_rstack_overflow=off roll back a microcode update though (or just the in kernel mitigations)? or does a custom kernel need to be compiled with multiple microcodes in it and one needing to be picked upon boot to get the benefit?
off - No Inception mitigations. All other CPU security mitigations were at their defaults… This testing is just looking at the Inception mitigation overhead.
safe RET no microcode - The purely kernel-based mitigation while using the prior Family 19h CPU microcode without the Inception mitigation there.
safe RET - The default safe RET mode when using the newest CPU microcode.
IBPB - The alternative IBPB-based mitigation approach.
On my 7950X host spec_rstack_overflow=off gives you this lscpu output: Vulnerable, no microcode
No microcode support yet on 7950X consumer cpu and boards.
On my Epyc 7713 host spec_rstack_overflow=off gives you this lscpu output: Vulnerable
Host has microcode support already.
With spec_rstack_overflow=off removed from the kernel command line on the 7713 this is the lscpu output:
hahah, we’re looking at the same phoronix article!
I’m going to be honest, before talking to you I didn’t even realize that the OS was patching CPU microcode (but only for the EPYC CPU?), I had thought it was solely up to the BIOS to load new/updated microcode into the CPU.
My assumption is that the new microcode is going to incur a performance hit, probably less than the kernel mitigations though.
This is what is making me think that:
