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

[F.Ultra]

Do you mean that Windows is ahead of Linux (and it has been such for years) in this respect, and no Linux developer ever dreamed of having the same feature in Linux, but they kept struggling with standard futexes instead, and only now that some Windows-only game would benefit from this, then the Linux world wakes up and realizes how good this feature is?

Seems to me hard to believe, but I hope you prove me wrong.

Having waitv interface for futex was first though of back in the day when futex was first implemented in Linux but no one managed to make it work good enough to have it mainlined so the whole idea was put on pause until the futex2 project brought it back to life.

That said, remember also that Windows does not have a waitv interface for futexes, their WaitForMultipleObjects cannot wait for futexes and have a limit of max 64 objects per call. Windows also got futexes some 10 years after Linux, which didn't stop the bastards from filing a patent for it anyway...

And in the end this is a convenience function, its not that it was impossible to wait on multiple objects in Linux before, just that you had to write your own notification handler for it.

[pipe13]

Great to see these patches for both s390 and s390.

Absolebulutely! I mean, you aren't a real Windows gamer unless you're gaming on the really Big Iron.

[microcode]

Do you mean that Windows is ahead of Linux (and it has been such for years) in this respect, and no Linux developer ever dreamed of having the same feature in Linux, but they kept struggling with standard futexes instead, and only now that some Windows-only game would benefit from this, then the Linux world wakes up and realizes how good this feature is?

Seems to me hard to believe, but I hope you prove me wrong.

I mean, there's lots of stuff like this out there. Linux has inotify, which is way better in most practical situations than the equivalents on FreeBSD, macOS, and Windows. OpenBSD had the best random number facilities for years before they were copied. Copying good ideas is an ongoing process, WaitForMultipleObjects happens to be a good idea, probably IO_URING will get copied too..

[lucrus]

WaitForMultipleObjects is not exotic, and futex_waitv will get more users over time (it is clearly a useful primitive.

Do you mean that Windows is ahead of Linux (and it has been such for years) in this respect, and no Linux developer ever dreamed of having the same feature in Linux, but they kept struggling with standard futexes instead, and only now that some Windows-only game would benefit from this, then the Linux world wakes up and realizes how good this feature is?

Seems to me hard to believe, but I hope you prove me wrong.

[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.

[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.

[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.

[George99]

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

Great to see these patches for both s390 and s390.

[uid313]

But what about on RISC-V?

[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.