The Combined Performance Penalty of Intel CPU bugs Zombieload, Meltdown, Spectre and L1TF

'Zombieload is just the latest of a torrent of security holes in Intel CPUs found the last year. Each has required mitigations both at the firmware and kernel level and the sum of these is adding up. Some workloads are barely affected, others have a very real, measurable and noticeable slowdown.

The following rather large data-set comparing the Intel Core i7 6800K and the Intel Core i7 8700K on Linux 5.0 from openbenchmarking with CPU bug mitigation off, on and on with SMT disabled shows that the cumulative impact is high. Turning SMT/HyperThreading off to be safe from L1TF and Zombieload has the biggest impact but the performance-penalty is high even if you leave SMT on.

Kernel Compilation

Compiling the kernel is something most Linux do sooner or later. Some do it regularly. The difference in compilation workloads is there when comparing standard mitigations vs no mitigations but it is only 3-4 seconds on a task that takes one and a half minute. Turning SMT off, which is required to stay safe from Zombieload-attacks, does have a huge impact. It is noticeable when a task which used to take one and a half minute takes more than two minutes.

File Compression

Like kernel compilation file compression is not noticeable affected by all the kernel mitigation code required to work around Intel's CPU bugs. The performance impact is barely measurable. However, disabling SMT does have a huge and very real impact. 10 seconds more on a task that takes 40 is a big deal.

4K Video encoding with dav1d

Video encoding is another use-case where SMT makes a noticeable difference. The impact of the kernel mitigation code alone is barely measurable.

Purely synthetic measurements

The Hackbench is a stress test for the Linux kernel scheduler. The impact when measuring 32 processes and time how long it takes for each pair to send data back and forth is huge when just looking at the standard mitigation code and it is enormous when turning SMT off.

Web Server Performance

Running a web-server is a real-world use-case where there is a lot of context switching. The performance-impact of the mitigation code alone is huge and very noticeable. The difference between standard kernel mitigations on and off is larger than the difference between SMT on and off. The total performance hit by mitigation code and disabling SMT is huge on this workload.

Conclusion

The sum of all the kernel mitigation code alone has a measurable but not gigantic impact on typical desktop tasks and workloads like video encoding, file compression and compilation. This changes when Hyper-Threading/SMT is turned off. Intel marketed Hyper-Threading as the differentiating feature between their i5 and more expensive i7 CPUs for years and years. Having to turn that more expensive i7 into a i5 to be safe from CPU security bugs is not a good thing. The performance impact is very apparent. This is probably why some companies, like Apple, recommend turning it off while others recommend leaving it on. RedHat and SuSE have gone with the "up-to-you" approach, their Linux distributions installers will soon briefly inform you what the implications are and ask you what you prefer.

The mitigation code's impact on server workloads is huge and the total when disabling SMT on top of that is gigantic. Home desktop users can take the risk and turn the mitigation code off and leave SMT to get the performance Intel CPUs were advertised to have. This is simply not an option for corporations running mission-critical services. Many will simply have to upgrade to newer CPUs or add more servers; the difference is such that a task which previously required 20 servers now require 30 to handle the same load.

There is no known example of websites using JavaScript or WebAssembly to exploit the known Intel CPU bugs as of today. Leaving SMT on or off will become less of a choice if/when that happens. For now it's more of a personal choice and it is not easy to make any recommendations one way or the other. The performance implications are real and very noticeable and apparent. The security risks may not seem that real, but they could potentially be very bad. We'll leave it up to you to decide how much risk you are willing to take.