Linus Torvalds has announced the release of Linux Kernel 5.16, bringing with it the usual assortment of new hardware support and improvements everywhere. Plus, there's something big for Linux gaming fans.

The one many have no doubt been waiting for is the inclusion of Collabora's work on FUTEX2 with futex_waitv(). This is supposed to help Linux gaming with Proton / Wine and also Native Linux gaming too. As Collabora developer André Almeida previously described it: "The use case of this syscall is to allow low level locking libraries to wait for multiple locks at the same time. This is specially useful for emulating Windows' WaitForMultipleObjects. A futex_waitv()-based solution has been used for some time at Proton's Wine (a compatibility layer to run Windows games on Linux). Compared to a solution that uses eventfd(), futex was able to reduce CPU utilization for games, and even increase frames per second for some games. This happens because eventfd doesn't scale very well for a huge number of read, write and poll calls compared to futex. Native game engines will benefit of this as well, given that this wait pattern is common for games.".

So with this Kernel version, plus a version of Proton / Wine and any Native games / game engines that support it, you might be able to see better performance.

Masses of other changes as well of course, although plenty of it most normal consumers won't be too excited about just yet. However a few noteworthy interesting bits for desktop / laptop users and gamers (more on KernelNewbies ) like:

• The addition of DisplayPort 2.0 for AMD GPU
• Initial USB4 DP tunnelling support for AMD GPU
• More work towards supporting Intel Xe discrete GPUs
• Improvements for the PlayStation 5 DualSense controller
• Better support of HP Omen laptops
• A small fix for the Steam Deck screen
• Nintendo Joy-Con and Pro Controller support

Last year, several security vulnerabilities were discovered, making it difficult for system administrators to patch the systems without downtime quickly. What if some improvements can be made to update some critical components for security/performance improvements without rebooting a system?

Intel aims to achieve that with its new PFRUT (Platform Firmware Runtime Update and Telemetry) driver. Note that this is only possible with a Linux system and an Intel chip on board.

As I recall SUSE Linux (kGraft) and Ubuntu (Livepatch) have had similar patching of the kernel, and although they were not claiming 100% rebooting never required, they did not appear to be tied to a particular CPU architecture, like Intel is currently doing. Either ways, it looks like this functionality is improving across the board, and as it is all open source, it can be improved upon by others too. The Intel advantage though is that this goes into the general kernel, so non SUSE and Ubuntu users with Intel, all stand to gain from it.

See https://news.itsfoss.com/intel-linux-kernel/

#technology #Linux #Intel #livepatching #kernel

After seven Release Candidates and two months of hard work, Linux kernel 5.15 is here and it’s ready for mass adoption as the latest LTS (Long-Term Support) kernel for GNU/Linux distributions. You can download it right now from the kernel.org website or from here (direct download link since kernel.org isn’t updated yet).

Highlights of Linux 5.15 include a brand new NTFS file system implementation from Parangon Software that’s fully functional and supports all NTFS versions up to 3.1, realtime preemption locking, an in-kernel SMB3 server called ksmbd, Btrfs now supports fs-verity file integrity assurance and ID-mapped mounts, as well as DAMON (Data Access MONitor) for monitoring the memory access pattern of user-space processes.

So this compatibility should also help where you have a Windows game in Steam Games on Linux sharing a NTFS partition with a dual-booted Windows boot up.

See https://9to5linux.com/linux-kernel-5-15-released-with-new-ntfs-file-system-in-kernel-smb-server-and-more

#technology #Linux #kernel #NTFS

Two major bits of news for the Linux Kernel today as not only has Linux 5.15 been released with lots new, we're also likely to finally see the futex2 work from Collabora in Linux 5.16.

Firstly for the new Linux 5.15 Kernel release, in the announcement x said:

It's been calm, and I have no excuse to add an extra rc, so here we are, with v5.15 pushed out, and the merge window starting tomorrow.

Which is going to be a bit inconvenient for me, since I also have some conference travel coming up. But it's only a couple of days and I'll have my laptop with me. Sometimes the release timing works out, and sometimes it doesn't..

Anyway, the last week of 5.15 was mainly networking and gpu fixes, with some random sprinkling of other things (a few btrfs reverts, some kvm updates, minor other fixes here and there - a few architecture fixes, couple of tracing, small driver fixes etc). Full shortlog appended.

This release may have started out with some -Werror pain, but it calmed down fairly quickly and on the whole 5.15 was fair small and calm. Let's hope for more of the same - without Werror issues this time - for the upcoming merge window.

Some of the highlights include:

• A new NTFS driver named 'NTFS3' contributed by Paragon Software.
• AMD Van Gogh APU audio driver support.
• High resolution scrolling support for the Apple Magic Mouse.
• More work for supporting Intel Alder Lake (12th-generation of Intel Core processors).
• Progress on Apple M1 support with the IOMMU driver in.
• Some initial support for Intels upcoming discrete Alchemist GPUs.
• Temperature monitoring for AMD Zen 3 APUs

A full technical changelog can be seen here (for an easier list though there's Kernel Newbies ).

For the futex2 work coming from Collabora developer André Almeida, another developer Thomas Gleixner has sent in a request for Linus Torvalds to have it included along with other work so we should see it in the next Kernel release. This is for the new system call sys_futex_waitv that will help Linux gaming.

As Almeida previously described it: "The use case of this syscall is to allow low level locking libraries to wait for multiple locks at the same time. This is specially useful for emulating Windows' WaitForMultipleObjects. A futex_waitv()-based solution has been used for some time at Proton's Wine (a compatibility layer to run Windows games on Linux). Compared to a solution that uses eventfd(), futex was able to reduce CPU utilization for games, and even increase frames per second for some games. This happens because eventfd doesn't scale very well for a huge number of read, write and poll calls compared to futex. Native game engines will benefit of this as well, given that this wait pattern is common for games.".

After a long bumpy road with many revisions, it appears that the futex2 work sponsored by Valve is finally heading into the upstream Linux Kernel . Initially much larger, the work was slimmed down to get the main needed parts done and enabled before the rest can make it in.

So what is it? As developer André Almeida previously described it: "The use case of this syscall is to allow low level locking libraries to wait for multiple locks at the same time. This is specially useful for emulating Windows' WaitForMultipleObjects. A futex_waitv()-based solution has been used for some time at Proton's Wine (a compatibility layer to run Windows games on Linux). Compared to a solution that uses eventfd(), futex was able to reduce CPU utilization for games, and even increase frames per second for some games. This happens because eventfd doesn't scale very well for a huge number of read, write and poll calls compared to futex. Native game engines will benefit of this as well, given that this wait pattern is common for games.".

Speaking on Twitter, Valve developer Pierre-Loup Griffais said "It's amazing news that futex_waitv() seems to be on its way to the upstream kernel! Many thanks to the continued efforts of our partners at Collabora, CodeWeavers, and to the upstream community.".

Ideally then this will help Windows games in Proton on Linux run better. But that's not all!

Also interesting is the follow-up post from Griffais that mentions "Beyond Wine/Proton, we are also excited to bring those multi-threaded efficiency gains to Linux-native game engines and applications through some variant of the following primitive, pending more discussion with the glibc community:" with a link to some glibc work.

Another day, another try and getting the long-awaited futex2 patches into the Linux Kernel with another version submitted.

For a quick reminder: this work from Collabora is designed to help Linux gaming for both native games and Windows games run through Wine and the Steam Play Proton compatibility layers. This work was cut-down to size in the hopes of getting the simpler work actually upstreamed into the Linux Kernel. The idea is to basically better match Windows behaviour to improve compatibility, as the developer notes:

The use case of this syscall is to allow low level locking libraries to wait for multiple locks at the same time. This is specially useful for emulating Windows' WaitForMultipleObjects. A futex_waitv()-based solution has been used for some time at Proton's Wine (a compatibility layer to run Windows games on Linux). Compared to a solution that uses eventfd(), futex was able to reduce CPU utilization for games, and even increase frames per second for some games. This happens because eventfd doesn't scale very well for a huge number of read, write and poll calls compared to futex. Native game engines will benefit of this as well, given that this wait pattern is common for games.

This is what has changed in the new version:

- Added a clockid argument in sys_futex_waitv()
- This required some changes in the timeout init
- Added test for wouldblock
- Added documentation file
- Fixed error path order for futex_wait_multiple()
- Return error if FUTEX_32 is not set for a waiter
- Extended futex_waitv() selftest to cover error paths like this

Coming as a result of feedback received at the recent Linux Plumbers Conference 2021 where Collabora developer André Almeida gave an overview of what it is and why it's needed:

It seems the ongoing saga of getting the futex2 work into the Linux Kernel, which is supposed to help Linux gaming and Steam Play Proton, has another attempt up. This is a continuation of the cut-down and more focused code that was submitted back in early August , as Collabora hope to finally get it accepted into the Kernel.

The key point is that this code is not just to help Windows games on Linux through Proton but to also help native games. While the code better matches behaviour found on Windows, anything that needs it can benefit. As developer André Almeida explains:

"The use case of this syscall is to allow low level locking libraries to wait for multiple locks at the same time. This is specially useful for emulating Windows' WaitForMultipleObjects. A futex_waitv()-based solution has been used for some time at Proton's Wine (a compatibility layer to run Windows games on Linux). Compared to a solution that uses eventfd(), futex was able to reduce CPU utilization for games, and even increase frames per second for some games. This happens because eventfd doesn't scale very well for a huge number of read, write and poll calls compared to futex. Native game engines will benefit of this as well, given that this wait pattern is common for games."

Since we last wrote about it, two new versions of it have been sent in so it's now on the third iteration with these changes and improvements:

Changes from v2:
v2: https://lore.kernel.org/lkml/20210904231159.13292-1-andrealmeid@collabora.com/
- Last version, I made compat and non-compat use the same code, but
failed to remove the compat entry point. This is fixed now.
- Add ARM support

Changes from v1:
v1: https://lore.kernel.org/lkml/20210805190405.59110-1-andrealmeid@collabora.com/
- Tons of code and comment improvements and fixes (thanks Thomas!)
- Changed the struct to have explicit padding (thanks Arnd!)
- Created a kernel/futex.h
- Splitted syscall table changes from the implementation
- Compat and non-compat entry point now uses the same code and same
struct
- Added test for timeout

You can see the patches on the Linux Kernel mailing list .

Currently limited to Zen 3, AMD has revealed their work on a brand new CPU frequency control mechanism "amd-pstate".

What's this for then? Well, it was previously announced that AMD along with Valve were working on it with a talk that was presented during the X.Org Developers Conference 2021. Seems this is it and they're ready to properly introduce it. Announced on the Linux Kernel mailing list from developer Huang Rui:

The new mechanism is based on Collaborative processor performance control (CPPC) which is finer grain frequency management than legacy ACPI hardware P-States. Current AMD CPU platforms are using the ACPI P-states driver to manage CPU frequency and clocks with switching only in 3 P-states. AMD P-States is to replace the ACPI P-states controls, allows a flexible, low-latency interface for the Linux kernel to directly communicate the performance hints to hardware.

"amd-pstate" leverages the Linux kernel governors such as *schedutil*, *ondemand*, etc. to manage the performance hints which are provided by CPPC hardware functionality. The first version for amd-pstate is to support one of the Zen3 processors, and we will support more in future after we verify the hardware and SBIOS functionalities.

There's a bit more of an explanation available in part 19 of the patchset, which goes over plenty more of the technical details if you want the real nitty-gritty.

Great to see AMD continue to advance their processors on Linux. Hopefully this will provide a better overall experience for all workloads, especially gaming. Highly likely this will benefit the likes of the Steam Deck too, which will be using a special Zen 2 AMD APU.