Tag Archives: Phoronix Test Suite

“Beyond Stupid” Paranoid L1d Cache Flushing Looks Like It Will Try Again For Linux 5.15


LINUX SECURITY --

The work going on for over a year to optionally flush the L1 data cache on context switching is going to try again for the next kernel cycle as an opt-in feature for select tasks. This was the feature rejected last year by Linus Torvalds that went on to “beyond stupid” and other concerns about it when it was trying to be mainlined originally.

This paranoid L1d cache flushing on context switch remains an opt-in feature and led by Amazon engineers. While frequently flushing the L1 data cache leads to significant performance implications, Amazon’s motivation is over the increasing number of CPU vulnerabilities with the likes of the CVE-2020-0550 improper data forwarding vulnerability and others along with concerns over other yet-to-be-found vulnerabilities.

After Linus Torvalds dismissed the functionality last year, the L1d cache flushing patches were revised for better handling where some CPU cores may have SMT/HT disabled. This functionality also won’t be available unless the kernel is booted with a special flag to enable it, while still needing to opt-in to the L1d flushing at context switch on a per-task basis via the prctl() interface. Further, the L1d flushing feature will be disabled for CPUs not affected by the Intel L1TF “Foreshadow” vulnerability. The software flushing of the L1d is no longer supported/used by this feature.

So in recap the current paranoid L1d flushing code will flush out the L1 data cache when a task is scheduled out and the incoming task is from a different process and only in cases where there is hardware-based L1d flushing available for vulnerable processors. The kernel must be booted with “l1d_flush=on” and then tasks can use PR_SPEC_L1D_FLUSH with prctl to enable the mitigation. By default there is no change to the kernel behavior.

The paranoid L1d flushing patches were queued up this morning via tip.git’s x86/cpu branch which unless reverted in turn will be sent in for the Linux 5.15 merge window opening up around the start of September — we’ll see what Linus Torvalds thinks of the feature in its current form.


RADV Ray-Tracing Now Rendering Quake II RTX Correctly But Very Slowly


RADEON --

The open-source Mesa RADV driver for independent Radeon Vulkan driver support on Linux has been working towards supporting ray-tracing for months. Progress is being made with the latest being more test cases passes and even the Quake II RTX game rendering correctly, but the performance is far short of being satisfactory yet.

Prominent RADV developer Bas Nieuwenhuizen has been working on the ray-tracing support for the RADV Vulkan driver for some time and making good progress even without AMD’s official open-source AMDVLK driver supporting ray-tracing (only their closed-source Vulkan driver currently exposes the Vulkan RT extensions).

Bas is seeing around a 90% pass-rate with the Vulkan conformance test suite for non-skipped tests but even more exciting is that he has now fixed the corruption issues previously plaguing their early Quake II RTX support.

While Quake II RTX corruption issues have been fixed, the performance is at roughly half of the Windows performance. The performance shortcoming is due to not yet tailoring the RADV ray-tracing for performance and missing important optimizations. Details on this slow ray-tracing support via Bas’ blog.

Once the Vulkan CTS is properly passing, they will be working to upstream the code in mainline Mesa. Additionally, work will get underway in trying to get DXR 1.0 games working with VKD3D-Proton. After that stage is likely when performance will go into focus for RADV ray-tracing.


Google Continues Working On Suspend-Only Swap Spaces For Linux


LINUX KERNEL --

Google engineers and other parties are interested in being able to create swap spaces on Linux systems that would be reserved just for system suspend/hibernation purposes and not for generic swapping to disk.

The proposed SWAP_FLAG_HIBERNATE_ONLY would reserve a swap space just for suspend-to-disk usage and not swapping regular pages. To now, generic swap ultimately needs to be enabled if just wanting to use it for system suspend, short of workarounds for turning it on/off around the suspend process.

Among the motives for suspend-only swap spaces:

There are a few reasons why usermode might want to be able to exclusively steer swap and hibernate. One reason relates to SSD wearing. Hibernate’s endurance and speed requirements are different from swap. It may for instance be advantageous to keep hibernate in primary storage, but put swap in an SLC namespace. These namespaces are faster and have better endurance, but cost 3-4x in terms of capacity. Exclusively steering hibernate and swap enables system designers to accurately partition their storage without either wearing out their primary storage, or overprovisioning their fast swap area.

Another reason to allow exclusive steering has to do with security. The requirements for designing systems with resilience against offline attacks are different between swap and hibernate. Swap effectively requires a dictionary of hashes, as pages can be added and removed arbitrarily, whereas hibernate only needs a single hash for the entire image. If you’ve set up block-level integrity for swap and image-level integrity for hibernate, then allowing swap blocks to possibly leak out to the hibernate region is problematic, since it creates swap pages not protected by any integrity.

Sent out today was the latest patch implementing this hibernate-only flag for swap. This revision changes the flag name and has various other code improvements for this proposed functionality.


Haiku R1 Beta 3 Released As Spiritual Successor To BeOS


OPERATING SYSTEMS --

One year after Haiku R1 Beta 2, the third beta of this inaugural release of the open-source Haiku operating system is now available for testing. Haiku remains the open-source OS project going on two decades for advancing as the spiritual successor to BeOS.

The Haiku Project this morning announced the release of Haiku R1 Beta 3. Haiku R1 Beta 3 includes work across the operating system stack with all of the changes made over the past year including around installation and storage, countless hardware driver improvements, various software application updates, greater POSIX compatibility, many bug fixes, translation updates, and much more.

Among the hardware driver work has been updating more network code from FreeBSD, better audio driver coverage along with mass storage and USB, and better performance on NVIDIA graphics cards. The NVIDIA GPU focus though has been on older GeForce 6000 series cards.

Downloads and more details on the long awaited Haiku R1 Beta 3 release via Haiku-OS.org.


Proposed Reflink Support Would Provide Big Space Savings For Wine


WINE --

When sticking to Wine recommendations of maintaining separate prefixes per-application, a lot of system files get duplicated for each game/application and in turn leading to significant bloat. With the current state of Wine it can mean hundreds of megabytes per prefix in duplicated files. But proposed reflink patches for Wine are aiming to cut down on this severe bloat.

Developer Alex Xu sent out a set of patches today that would implement Reflink support within Wine. Alex explained, “ With a MinGW build of Wine without Mono or Gecko, new 32-bit prefixes are over 150 MB, and new 64-bit prefixes are over 300 MB. The vast majority of these files are byte-for-byte identical to Wine’s central DLL copies…When reflink is supported by the underlying filesystem, new Wine prefix sizes with Mono and Gecko disabled are reduced to less than 1 MB. The resulting Wine prefix is byte-for-byte identical to one created without reflink, but occupies less space on disk.

Reflinks are currently supported by Btrfs, XFS, and others but notably not supporting it is EXT4. Reflinks are used rather than hard/symbolic links since cases like Winetricks modifying a given Wine prefix would in turn modify the original copy used by the other prefixes while reflinks will still allow for independence between the prefixes.

So with these proposed 4 patches providing the Reflink support, Wine prefix size could drop from 150~300+ MB per prefix down to 1MB or less, assuming you are on a supported file-system, which will quickly add up if installing/managing many Windows games or applications on your system.