Tag Archives: Phoronix Test Suite

Ryzen CPUs On Linux Finally See CCD Temperatures, Current + Voltage Reporting

AMD --

One of the few frustrations with the AMD Ryzen CPU support on Linux to date has been besides the often delayed support for CPU temperature reporting has been the mainline kernel not supporting voltage readings and other extra sensors. But that is finally changing with the “k10temp” driver being extended to include current and voltage reporting plus CCD temperature reporting on Zen 2 processors.

There has been the out-of-tree Zenpower driver and other efforts to provide this information on Linux but hasn’t been officially backed by AMD and not mainlined in the kernel, thus greatly reducing the exposure to potential users. But now the k10temp driver is finally being extended to include these extra information outputs.

Linux HWMON maintainer Guenter Roeck has been working on these driver improvements to k10temp. Besides some code improvements, the new patches support reporting Core Complex Die (CCD) temperatures on Zen 2 processors. Additionally, for Ryzen CPUs (Zen 1 included) are core/SoC current and voltage information.

With this for current Ryzen 3000 series processors the patched k10temp Linux driver should expose Vcore, VSoc, Tdie, Tctl, Tccd1, Tccd2, Icore, and Isoc outputs.

Guenter posted these patches to the kernel mailing list. He’s looking for more testing on these k10temp improvements before he will queue them up for mainline kernel inclusion… Thus if you are hoping to see this work for the upcoming Linux 5.6 cycle, you better start doing some testing on AMD CPUs ASAP and pass along your findings (and, yes, I’ll be joining in on this testing party). Regardless of whether it happens for Linux 5.6 or takes another cycle, at least these driver improvements are now happening and hopefully moving forward AMD engineers will be able to make more proactive contributions.

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.

A Slew Of ACO Optimizations For The Radeon Vulkan Driver Landed In Mesa 20.0


The Valve-backed ACO compiler back-end that is optionally used by the RADV Radeon Vulkan driver has continued growing in popularity with Linux gamers and also has continued maturing a lot for Mesa 20.0 that is due out later this quarter.

On top of the work that has merged already for ACO since its original mainlining in Mesa 19.3, optimizations and fixes are aplenty for ACO with RADV come Mesa 20.0.

Merged yesterday were instruction combining improvements for ACO that can particularly benefit Navi/GFX10 but also older generations. With the combining work, the number of instructions used when compiling shaders for popular games dropped by about 2.4%.

Separately merged were patches that have been around for about two months on uniform boolean optimizations. This helps a very tiny bit in the slightly smaller code size.

This and other ACO work will make for fun Mesa 20.0 testing shortly. Mesa 20.0 should be hitting its release candidate / feature freeze around the end of January and ideally releasing as stable about one month later, pending any blocker bugs pushing back the release for any significant amount of time.

The Time Namespace Appears To Finally Be On-Deck For The Mainline Linux Kernel


Back in 2018 a time namespace was proposed for the Linux kernel and now in 2020 it looks like this kernel functionality will be merged for mainline, likely with the upcoming Linux 5.6 cycle.

A few hours ago the time namespace patches were queued in the timers/core Git branch ahead of the Linux 5.6 merge window opening at the start of February.

The time namespace allows for per-namespace offsets to the system monotonic and boot-time clocks. The time namespace is suited for Linux containers usage for allowing the date/time to be changed within a container and for adjusting clocks within a container following restoration from a checkpoint/snapshot.

The patch introducing the time namespace further explains:

For many users, the time namespace means the ability to changes date and time in a container (CLOCK_REALTIME). Providing per namespace notions of CLOCK_REALTIME would be complex with a massive overhead, but has a dubious value.

But in the context of checkpoint/restore functionality, monotonic and boottime clocks become interesting. Both clocks are monotonic with unspecified starting points. These clocks are widely used to measure time slices and set timers. After restoring or migrating processes, it has to be guaranteed that they never go backward. In an ideal case, the behavior of these clocks should be the same as for a case when a whole system is suspended. All this means that it is required to set CLOCK_MONOTONIC and CLOCK_BOOTTIME clocks, which can be achieved by adding per-namespace offsets for clocks.

A time namespace is similar to a pid namespace in the way how it is created: unshare(CLONE_NEWTIME) system call creates a new time namespace, but doesn’t set it to the current process. Then all children of the process will be born in the new time namespace, or a process can use the setns() system call to join a namespace.

Following that initial patch are many follow-up patches as part of this series for making other elements of the Linux kernel timing code namespace aware and properly exposing the namespaced times. Tests are also included as part of this big rework.

Fedora 32 Greenlit For Enabling FSTRIM Support By Default


Back in December was the proposal to finally enable FSTRIM by default for Fedora 32 in benefiting solid-state storage. Today the formal approval was given by the Fedora Engineering and Steering Committee to go ahead with this long overdue change.

The change is to enable the systemd fstrim.timer unit by default for running FSTRIM weekly on EXT4/XFS/Btrfs/F2FS file-systems running on flash-based storage devices. FSTRIM is used for notifying the underlying storage devices about unused blocks for wear leveling and more efficient handling.

Existing Fedora releases can toggle the support on via systemctl enable fstrim.timer while starting with Fedora 32’s release this April it will be enabled by default.

FSTRIM received approval at today’s FESCO meeting along with the change for using update-alternatives on cc and c++ for making it easier to drop in alternative compilers.

Fedora 32 is shaping up to be another great release.