FUTEX2 futex_waitv Wired Up For Other Architectures With Linux 5.16-rc3

[phoronix]

Phoronix: FUTEX2 futex_waitv Wired Up For Other Architectures With Linux 5.16-rc3

FUTEX2 as in the new futex_waitv system call landed in Linux 5.16 back during the merge window for improving the efficiency of running Windows games on Linux for those that rely on Windows' WaitForMultipleObjects functionality with futex_waitv is now the ability to wait on multiple futexes. That new system call is now supported on more architectures with the next Linux 5.16 release candidate...

https://www.phoronix.com/scan.php?page=news_item&px=FUTEX2-futex-waiv-More-Archs

[Developer12]

I find the prospect of futex2 being available on the itanic downright hilarious.

[microcode]

I find the prospect of futex2 being available on the itanic downright hilarious.

Hey; believe it or not there is still a significant install base of Itanium machines running fresh Linux, and many of them are doing pretty important work.

[microcode]

I like how the wine gaming use case has exposed a genuinely good reason to add a new syscall, something we rarely have these days.

[Developer12]

Hey; believe it or not there is still a significant install base of Itanium machines running fresh Linux, and many of them are doing pretty important work.

I have a hard time imagining anyone running modern linux on itanium for anything except a hobby. If any business is still running itanium I would expect it to be for some old application that probably also requires HP-UX (or some ancient 2.6.x.y linux). x86_64 servers are a dime a dozen these days.

[uid313]

But what about on RISC-V?

[George99]

Patches since then enabled the system call for MIPS, s390, parisc,and s390.

Great to see these patches for both s390 and s390.

[lucrus]

Let me understand (e.g. please correct me where I'm wrong): futex2 (by Valve) was accepted into mainline because there is a userspace GPL'd client that makes use of it, which is Wine (with patches from Valve). Wine itself uses it only to let proprietary, binary only Windows games (sold by Valve) run faster.

Now let's consider this hypotetical situation: NVidia (instead of Valve) asks to mainline a new syscall (let's call it futex3) and they release a stub GPL'd client library (let's call it lib-nv-wine). All that because they sell a proprietary, binary only Blender Add-On that needs lib-nv-wine and, in turn, futex3.

Please note I hate NVidia, but I can't tell the difference.

[microcode]

Let me understand (e.g. please correct me where I'm wrong): futex2 (by Valve) was accepted into mainline because there is a userspace GPL'd client that makes use of it, which is Wine (with patches from Valve). Wine itself uses it only to let proprietary, binary only Windows games (sold by Valve) run faster.

That's inaccurate to start. There's plenty of free software that happens to have been built first on Windows, WaitForMultipleObjects is not exotic, and futex_waitv will get more users over time (it is clearly a useful primitive.

[344 hertz]

Having the ability to wait for multiple futexes seems to be a useful option for games in general. It is because windows games use this option on windows that it is most immediately needed for WINE, but it is not strictly tied to emulation. Rather it is useful for games, most of which require emulation. But Linux native games would benefit from this as well, assuming game engines start making use of it. In fact, valve has hinted that they would like developers to make Linux native builds of their games. So no, futex2 is not strictly in the effort of running windows binaries. That happens to be the most immediate use case.