Initial Benchmarks Of The Intel Downfall Mitigation Performance Impact

Written by Michael Larabel in Software on 9 August 2023 at 04:00 PM EDT. Page 5 of 5. 46 Comments.
Tiger Lake AVX Workloads

I'm still running more benchmarks exploring other possible workloads being impacted by the Downfall microcode mitigation as well as more client-oriented workloads... Obviously the server workloads came first in being able to churn those out faster thanks to the speed of the higher core count parts. But from some initial testing on an Intel Tiger Lake notebook with Core i7-1165G7, the same performance penalties for workloads like the Intel OSPRay / OpenVKL / Embree and DeepSparse were again among the real-world workloads indicating a measurable hit to the performance with the new microcode. Obviously for HPC software like QMCPACK I didn't bother testing it on a Tigerlake notebook.

OpenVKL benchmark with settings of Benchmark: vklBenchmark ISPC. 0xa6 was the fastest.
OSPRay benchmark with settings of Benchmark: particle_volume/ao/real_time. 0xa6 was the fastest.
OSPRay benchmark with settings of Benchmark: particle_volume/pathtracer/real_time. 0xa6 was the fastest.

Those are the initial benchmarks I've been able to carry out of workloads I've found to be impacted in less than 24 hours since the Intel Downfall vulnerability was made public. As Phoronix is a one-man-band I am still battling away with exploring more workloads to be impacted by the mitigation but at least AVX2/AVX-512 workloads without using the VGATHER* instructions (or not within any hot code paths) are not impaired and showing the same level of performance as with prior microcode revisions. However, there still are certainly some workloads like various AI software and some Intel oneAPI open-source components that do indeed carry very measurable overhead now as a result of the Downfall mitigations. Stay tuned to Phoronix for more testing as I explore more workloads, especially on the client side with Intel Core CPUs and the more diverse workloads on that side of the computing spectrum.

For those on Skylake to Ice Lake / Tigerlake and running workloads affected by the GDS/Downfall mitigation but feel you are not prone to being exploited by Downfall, the Linux kernel with yesterday's patches does add the gather_data_sampling=off kernel option for disabling the mitigation even if using the newest microcode. The mitigations=off route will also disable the mitigation.

If you enjoyed this article consider joining Phoronix Premium to view this site ad-free, multi-page articles on a single page, and other benefits. PayPal or Stripe tips are also graciously accepted. Thanks for your support.


Related Articles
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.