Updated FUTEX2 System Call Patches Posted For Helping Wine/Proton, Other Use-Cases

[phoronix]

Phoronix: Updated FUTEX2 System Call Patches Posted For Helping Wine/Proton, Other Use-Cases

It's been several months since the last round of FUTEX2 patches for this system call to address the shortcomings of the current FUTEX system call. FUTEX2, which is designed in part with Wine/Proton in mind for better matching Windows semantics, has now seen a third iteration of the patches...

https://www.phoronix.com/scan.php?page=news_item&px=FUTEX2-System-Call-v3

[jacob]

I'm not an expert on this but why does FUTEX2 need special support for waiting on multiple futexes? Isn't that already covered by epoll_wait()?

[discordian]

I'm not an expert on this but why does FUTEX2 need special support for waiting on multiple futexes? Isn't that already covered by epoll_wait()?

Normal mutex/futex dont have a filedescriptor, cant be used with epoll. Dont know if FUTEX2 are filedescriptors, but even if.. epoll has overhead for setup, and multiple threads could wait for different sets concurrently

[CochainComplex]

I'm using these patches since a while via xanmod kernel + proton-ge-6.5 there are for sure performance uplifts. e.g. AC:Origin benchmark has way less stutter on ultra settings.

[baryluk]

I'm not an expert on this but why does FUTEX2 need special support for waiting on multiple futexes? Isn't that already covered by epoll_wait()?

epoll / eventfd doesn't scale well to big number of futexes / sync primitives. Also it has major overheads, and the semantic is not exactly what the wine wants to emulate Windows NT. The futex2 addresses many issues to make it all just work instead. futexes that are not being waited on doesn't consume any kernel resources or extra memory, there are no file descriptors, it is just a piece of user space memory, so you can have millions of futexes with no real drawbacks (especially if now it is possible to have 8-bit futexes, instead of 32-bit ones).

[ms178]

Just a 4% performance improvement for up to 800 threads and a decrease of 21% for requeue, the numbers don't look that great yet to me. I hope there is potential to improve the performance further.

[CochainComplex]

Just a 4% performance improvement for up to 800 threads and a decrease of 21% for requeue, the numbers don't look that great yet to me. I hope there is potential to improve the performance further.

Throughput (fps) hasn't changed that much in gaming situation but I definitely have less stutter. But even tough 4% is the equivalent of next higher cpu. or the difference between XT and non-XT with AMD cards.

[ms178]

Throughput (fps) hasn't changed that much in gaming situation but I definitely have less stutter. But even tough 4% is the equivalent of next higher cpu. or the difference between XT and non-XT with AMD cards.

I welcome every improvement, but I hoped for a bit more than 4% in a micro-benchmark. After all it is quite a substantial change which touches glibc, the kernel and wine. Reading the description of patch 4 makes me hopeful that the regression can be overcome in the future.

[marios]

Does anyone know if it has any other use cases, except of Wine?

[d3coder]

Does anyone know if it has any other use cases, except of Wine?

Game engines, Source 2 will use it; heavily threaded programs