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 Linus Torvalds 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
Linux 5.15 is also a LTS (long-term support) release, so it will be supported fully until at least October 2023 as announced by developer Greg Kroah-Hartman.
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.".
Article taken from GamingOnLinux.com.
It's a bit of a worry seeing this cited as the main use case for futex2, given that the last I heard from Zebediah (developer of the "fsync" patchset) on that topic was:
"this isn't really accurate" (2) ... "it is an out-of-tree implementation" (2) ... and "will remain out-of-tree due to compatibility and robustness problems" (2)
Before going on to say:
"I believe there is potential for an upstreamable implementation
which does not rely on futex or futex2." (2)
These quotes are from an older thread post to the kernel mailing list, but were in response to using Wine as justification for the inclusion of futex2.
(1) https://lore.kernel.org/lkml/163572864413.3357115.7664423060313420054.tglx@xen13/
(2) https://lkml.org/lkml/2021/6/4/20
Last edited by redmcg on 2 November 2021 at 7:42 pm UTC
"The main use case is emulating Windows' WaitForMultipleObjects which allows Wine to improve the performance of Windows Games." (1)Presumably something must have changed or someone else must have had a different opinion or it wouldn't now be going into the kernel.
It's a bit of a worry seeing this cited as the main use case for futex2, given that the last I heard from Zebidiah (developer of the "fsync" patchset) on that topic was:
"this isn't really accurate" (2) ... "it is an out-of-tree implementation" (2) ... and "will remain out-of-tree due to compatibility and robustness problems" (2)
Before going on to say:
"I believe there is potential for an upstreamable implementation
which does not rely on futex or futex2." (2)
These quotes are from an older thread post to the kernel mailing list, but were in response to using Wine as justification for the inclusion of futex2.
(1) https://lore.kernel.org/lkml/163572864413.3357115.7664423060313420054.tglx@xen13/
(2) https://lkml.org/lkml/2021/6/4/20
I do get the impression there have been significant revisions to the implementation over time.
Last edited by Purple Library Guy on 1 November 2021 at 8:58 pm UTC
(2) https://lkml.org/lkml/2021/6/4/20
If I interpreted this correctly, the author was saying that the futex2 code is in a Proton patch, not in WINE. He is suggesting that WINE will never take that code, presumably because the existing code is more broadly compatible (i.e. with macOS?). Whether that is true or not, I'm not sure - but we know they also won't take DXVK, for example.
If I interpreted this correctly, the author was saying that the futex2 code is in a Proton patch, not in WINE.
That's correct. And to be to fair to Collabora, it looks like they did then change their coverletter to be more accurate:
"Proton's (a set of compatibility tools to run Windows games) fork of Wine benefits of this feature to implement WaitForMultipleObjects from Win32 in a performant way" [1]
Although, I think some would argue that fsync only provides a benefit for some games.
Zebediah herself contributed a proposal to the mailing list in January this year [2]. If anyone is interested in the gory details of the problem, it's worth a read.
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://lkml.org/lkml/2021/1/17/312
Last edited by redmcg on 2 November 2021 at 7:42 pm UTC
Patreon
PayPal
See more from me