4 ms·
These seems to be linux's own mitigations against L1TF. There's no mention about microcode being updated here, which I assume isn't the case. I assume the micr
by polkadotted 8y ago
These seems to be linux's own mitigations against L1TF. There's no mention about microcode being updated here, which I assume isn't the case.
I assume the microcode update could be either equal o slightly worse in terms of performance, as the CPU might need to flush more frequently.
Which is pretty sad, as the status of kernel+microcode updates is quite confusing already. Some mitigations can take advantage of new microcode updates, if the kernel is recent enough. How does the pure soft-workaround compare in terms of performance to the microcode-assisted one?
Note that, combining all workarounds for meltdown+spectre-v1/v2+l1tf can have a significant performance hit for some workloads which are not purely cpu-bound. On top of that HT is now looking like a bad idea to start with.
I'm pretty sure that for a server where there's a lot of I/O and virtualization going on, enabling all the patches and workarounds + disabling HT can take a massive cut in overall throughput.
- GrayShade 8y agoI assumed the tests were were ran on the new microcode version, as it was released a week before the tests, but it seems that Ubuntu didn't ship that update yet. Their security advisory says that > Optimized L1 data cache flushing is available via intel-microcode updates. The updated kernels implement a software fallback cache flushing mechanism for processors that have not received microcode updates. It looks like the kernel will say "VMX: conditional cache flushes" on the new microcode so according to the Phoronix screenshots, they were running the older version. Maybe we'll see a new set of benchmarks.