4 ms·

Phoronix already tested this: https://www.phoronix.com/scan.php?page=article&item=l1tf-early-look&num=1 https://www.phoronix.com/scan.php?page=article&item=l1tf

Phoronix already tested this: https://www.phoronix.com/scan.php?page=article&item=l1tf-early-look&num=1 https://www.phoronix.com/scan.php?page=article&item=l1tf-ear... and https://www.phoronix.com/scan.php?page=article&item=l1tf-foreshadow-xeon&num=1 https://www.phoronix.com/scan.php?page=article&item=l1tf-for.... The performance loss isn't that bad in most cases.

sir-alien 8y ago
You might be right in "most" cases but looking at the benchmarks, there is quite a few cases which are used a lot in everday computing where performance literally hits rock bottom. Video rendering went from 600 frames per second down to 200 frames per second. That is a 60% or more performance loss.
- GrayShade 8y ago
  Look at the default mitigation; the full one disables HT. Unless you're a cloud provider, the default is probably enough.
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 ago
  I 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.
tssva 8y ago
The linked articles state the testing was done with the mitigations provided in the latest kernel enabled. It does not say that the microcode updates were applied during the testing. Also there was significant reduced performance when hyperthreading was disabled as required to fully mitigate the threat of the vulnerabilities. If the microcode update changes the behavoir of hyperthreading in order to fully mitigate the vulnerabilities without having to completely disable it then there is a chance these changes effect the performance benefit of hyperthreading. Given Intel's anti-benchmark license clause without evidence otherwise I assume it is not just a chance but a strong likelihood that the performance benefits are significantly impacted.

sir-alien 8y ago

You might be right in "most" cases but looking at the benchmarks, there is quite a few cases which are used a lot in everday computing where performance literally hits rock bottom. Video rendering went from 600 frames per second down to 200 frames per second. That is a 60% or more performance loss.

GrayShade 8y ago
Look at the default mitigation; the full one disables HT. Unless you're a cloud provider, the default is probably enough.

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 ago
I 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.

tssva 8y ago

The linked articles state the testing was done with the mitigations provided in the latest kernel enabled. It does not say that the microcode updates were applied during the testing. Also there was significant reduced performance when hyperthreading was disabled as required to fully mitigate the threat of the vulnerabilities. If the microcode update changes the behavoir of hyperthreading in order to fully mitigate the vulnerabilities without having to completely disable it then there is a chance these changes effect the performance benefit of hyperthreading. Given Intel's anti-benchmark license clause without evidence otherwise I assume it is not just a chance but a strong likelihood that the performance benefits are significantly impacted.