Tag Archives: Performance

Intel’s Mitigation For CVE-2019-14615 Graphics Vulnerability Obliterates Gen7 iGPU Performance


Yesterday we noted that the Linux kernel picked up a patch mitigating an Intel Gen9 graphics vulnerability. It didn’t sound too bad at first but then seeing Ivy Bridge Gen7 and Haswell Gen7.5 graphics are also affected raised eyebrows especially with that requiring a much larger mitigation. Now in testing the performance impact, the current mitigation patches completely wreck the performance of Ivybridge/Haswell graphics performance.

The vulnerability being discussed and analyzed this week is CVE-2019-14615. This CVE still hasn’t been made public over 24 hours later (though there are the Intel SA-00314 details for this disclosure), but from going through kernel patches and other resources, it certainly caught our interest right away and have been benchmarking it since yesterday evening. The CVE-2019-14615 vulnerability amounts to a new information disclosure issue due to insufficient control flow in certain data structures. Local access is required for exploiting this control flow issue in the hardware, but it’s not yet known/published if say WebGL within web browsers could exploit this issue. This is a hardware issue with all operating systems being affected. Our testing today, of course, is under Linux.

With the Intel Gen9 graphics mitigation it’s resorting to clearing all execution unit (EU) state at each context switch. That patch was merged to mainline right away and quickly backported to the stable series seeing new point releases. All is fairly well there (including minimal performance impact, as to be shown in this article) but with the Gen7/Gen7.5 mitigation is where the situation becomes quite messy.

The Gen7 graphics mitigation is much larger across two patches and relies upon a custom EU kernel being called prior to every context restore for clearing EU and URB resources. (Gen8 Broadwell graphics is already protected from a prior workaround.) With these patches for Gen7 graphics generation not being merged to mainline and the patch noting that “more analysis is performance on the performance implications,” we expected the graphics performance to take a hit but we didn’t expect it to be as dramatic as what we’re seeing!

First of all, for the very common Gen9 graphics that is basically found on all current Intel PCs besides Gen11 Icelake, the performance hit is indeed minimal… In just some Java 2D micro-benchmarks of its OpenGL pipeline were there any measurable hits to the performance. The Gen9 performance overall had no real impact from its clearing of EU state between context switches. The Gen9 graphics testing was done on an Intel Core i9 9900KS system and using Linux 5.5 Git from yesterday/today during which the mitigation was applied. So that’s all dandy, but when it comes to Gen7 graphics is where there is a major problem:

With this Haswell Core i7 4790K benchmarking, the Java text rendering performance saw its performance even drop like crazy — not to mention the huge hits to various OpenGL games. Granted, not many games run nicely going back to Haswell/Ivybridge era. But the open-source continuation of Enemy Territory saw its frame-rate more than halved with its mitigation. With all of the other games tested were very sizable hits to the frame-rates.

When taking the geometric mean of the i7-4790K, the mitigated results for this new vulnerability saw the HD Graphics 4600 performance drop down to 58% the performance prior to mitigating this single vulnerability.

But this is just the teaser data, continue on for more details on not only the Core i7 4790K but also having re-tested the Core i7 3770K after being shocked at the CVE-2019-14615 mitigation hit for Gen7.


Power Management Improvements Could Benefit Intel Server Performance In Linux 5.6


INTEL --

Some Intel server platforms could see better performance with the Linux 5.6 kernel cycle.

Intel’s Rafael Wysocki who also serves as the Linux kernel’s power management subsystem maintainer has been queuing some patches recently in working on ACPI _CST support around the Intel-Idle driver. With the final patch for using ACPI _CST on server systems with the Intel-Idle driver, Rafael explained:

In many cases, especially on server systems, it is desirable to avoid enabling C-states that have been disabled in the platform firmware (BIOS) setup, except for C1E.

As a rule, the C-states disabled this way are not listed by ACPI _CST, so if that is used by intel_idle along with the specific table of C-states that it has for the given processor, the C-states disabled through the platform firmware will not be enabled by default by intel_idle.

This updated behavior applies for server platforms back to Nehalem and each generation there after as part of the server or X-Series.

With this updated intel_idle driver behavior, Intel’s own monitoring is showing around a 12.6% improvement for FS-Mark that is a file-system benchmark but the CPU performance plays an important role too. It will be interesting to see how this Intel server power management behavioral change affects other workloads as well, which we’ll begin benchmarking shortly.

The Linux 5.6 merge window should be open around the end of January or early February. Until then the Linux power management work for Intel and other hardware will continue queuing as usual within linux-pm.git’s linux-next.


AMD Radeon RX 5500 XT Linux Performance Review


AMD today is shipping the Radeon RX 5500 XT as the new sub-$200 Navi graphics card. This 7nm graphics card offers 22 compute units, 1408 stream processors, up to 5.6 TFLOPS of compute power, 4GB or 8GB GDDR6 video memory options, and built atop their modern RDNA architecture and supporting features in common with the RX 5700 series like PCIe 4.0 support. Here is a look at the initial Linux gaming performance of the AMD Radeon RX 5500 XT with various gaming benchmarks and Steam Play tests as well.

The Radeon RX 5500 XT 4GB version is launching at $169 USD while the Radeon RX 5500 XT 8GB version will command $199 USD. These price points put them comparable to the current Radeon RX 580 / 590 retail cards. AMD markets the RX 5500 XT as offering 1.6x the performance-per-Watt of the original Polaris Radeon RX 480 and designed for 1080p gaming to go up against NVIDIA’s GeForce GTX 1650 SUPER graphics card.

A variety of AIB partners will be launching their Radeon RX 5500 XT models today with custom coolers in both 4GB and 8GB variants. The Radeon RX 5500 XT has a rated board power of 130 Watts.

For our launch-day Linux benchmarking we were provided with a Sapphire Radeon RX 5500 XT 4GB graphics card. As of writing we haven’t had access to any 8GB version for benchmarking.


Firefox 71 Linux Performance Isn’t Looking All That Great


MOZILLA --

With each new release of Firefox we set out to see how the performance is looking on the Linux desktop. One discovery we’ve made is that when using Intel’s Clear Linux the Firefox performance is a lot more competitive to Google Chrome than we traditionally see on Ubuntu Linux. But with Firefox 71 we’re seeing the performance trending lower compared to Firefox 69 and 70.

Here are some benchmarks of Firefox 69 / 70 / 71 builds using the official Mozilla binaries along with Chrome 78. All of the benchmarks freshly done from the same system that this time around was running Clear Linux.

Considering the end of the year is quickly approaching, I’m also working on a much larger Firefox Linux performance comparison going back many more releases. Stay tuned for that soon.

In some of the JavaScript benchmarks, Chrome continues to win over Firefox by a landslide. In the case of ARES-6, the performance is unchanged with Firefox 71.

With Octane, the Firefox 71 performance is pulling back slightly while Chrome remained faster than Firefox on Linux.

WebXPRT was also trending lower with Firefox 71 but at least here the Mozilla browser outperformed Chrome.

Basemark was also slower with the newly-minted Firefox 71 while Chrome 78 is much faster.

JetStream regressed with Firefox 71.

The HTML5 Canvas benchmark of CanvasMark was about the same and doing much better with Firefox at least on the Intel graphics.

Firefox 71 tended to be either the same speed or slower compared to Firefox 70.

Firefox continues running faster than Chrome at least with WebAssembly. Firefox 71 though overall wasn’t too exciting on the Linux performance front with either being the same speed as Firefox 70 or slower. At least though Firefox 71 does bring a few new features.


Linux 5.5 Seeing Some Wild Swings In Performance – Improvements But Also Regressions


LINUX KERNEL --

While there still is a week to go in the Linux 5.5 merge window with more feature code still landing, due to scheduler changes and other work already having landed, I already started running some Git benchmarks. Linux 5.5 at this stage appears quite volatile with some really nice improvements in some workloads but also regressions in others.

I started off some Linux 5.5 Git benchmarks a few days ago after seeing the scheduler changes land that are rather heavy this cycle and other work. Plus I wanted to test out some new features like the NVMe hwmon thermal reporting.

I started off with a Cascade Lake system just as it was available and curious to see the impact with a large server.

To much surprise, there were much more swings than we are used to seeing between kernel revisions — especially with no change in mitigations for any security vulnerabilities between Linux 5.4 and 5.5 Git… Some workloads like Rodinia and Parboil were seeing real improvements with Linux 5.5. The Facebook-developed Hackbench Linux kernel scheduler benchmark was also seeing significant improvements with Linux 5.5, likely explaining at least some of the 5.5 benefits coming from the new scheduler code. But there were also cases like PostgreSQL, Memcached, Pennant, and others seeing severe to small regressions where Linux 5.4 was running faster. (See all of this system’s data via this OpenBenchmarking.org result file.)

Not used to seeing such large shifts in Linux kernel performance especially with no mitigation changes, I fired up a completely separate system and ran largely the same benchmarks while again comparing Linux 5.4.0 to Linux Git this week.

On this Skylake server, Hackbench was again much faster on Linux 5.5 likely pointing to the scheduler changes explaining the boosts. Parboil and Rodinia continued to see improvements while Memcached, PostgreSQL, and Stress-NG System V message passing tests were among the cases seeing lower performance. So for many of the same workloads, they reproduced on this different Linux server. (All the data via this OpenBenchmarking.org result file.)

Curiosity got the best of me so I also fired up an AMD EPYC 7601 2P Dell PowerEdge server.

Wild swings again. Stress-NG System V Message Passing, PostgreSQL, and some other micro-benchmarks also showed better performance on Linux 5.4 than 5.5 Git… Meanwhile, Hackbench, Rodinia, and Parboil all showed improvements off Linux 5.5 Git. So at least from a quick examination, this AMD server is seeing similar behavior out of Linux 5.5 Git to the Intel Xeon boxes. (The EPYC result file.)

So while only half-way through the merge window, there does appear to be some compelling performance improvements to find with Linux 5.5 at least for larger systems. But at the same time there are some workloads seeing clear pull-backs in performance compared to Linux 5.4 stable. As the Linux 5.5 merge window settles down I’ll be carrying out more benchmarks as hadn’t expected to see such swings and normally don’t between kernel releases at this stage. Those enjoying all the Linux benchmarking found at Phoronix, you can show your support this holiday.