Announcement

Collapse
No announcement yet.

FUTEX2's sys_futex_waitv() Sent In For Linux 5.16 To Help Linux Gaming

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FUTEX2's sys_futex_waitv() Sent In For Linux 5.16 To Help Linux Gaming

    Phoronix: FUTEX2's sys_futex_waitv() Sent In For Linux 5.16 To Help Linux Gaming

    As expected after first reporting on it a month ago when the FUTEX2 patches were queued up in locking/core, this work with the new sys_futex_waitv() system call for helping the Windows on Linux gaming experience will indeed land for Linux 5.16...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    So does this completely replace the Esync/Fsync implementations or is this something different? I would be interested to see what the real world differences with this new implementation are.

    Comment


    • #3
      Originally posted by LeJimster View Post
      So does this completely replace the Esync/Fsync implementations or is this something different? I would be interested to see what the real world differences with this new implementation are.
      This is FSync. Right no you need for Fsync patched kernel. This mainlaine that patches.

      Comment


      • #4
        It can be already used by installing/compiling Xanmod kernel. https://xanmod.org/

        as said by @akuthr its fsync.

        If you are using Lutris just enable fsync.
        Once your Wine Version (e.g. most recent Proton-GE) and your Kernel e.g. the Xanmod kernel have the latest patchset implemented in the Lustris Game log you will see that instead of "fsync up and running" "fsync2 up and running" will appear.

        Comment


        • #5
          Right, thanks for clearing that up. I got a bit confused with the different implementations and how many times this "futex2" has been reworked, I wasn't sure if was a replacement for the current Fsync or not.

          Comment


          • #6
            I had to look up what the word futex actually means, because it did not quite strike me as being of greek or latin origin.

            So for anyone in the same boat as me, it stands for Fast User-Space Mutex (and mutex itself stands for mutual exclusion).

            Comment


            • #7
              Originally posted by sdack View Post
              I had to look up what the word futex actually means, because it did not quite strike me as being of greek or latin origin.

              So for anyone in the same boat as me, it stands for Fast User-Space Mutex (and mutex itself stands for mutual exclusion).
              And it is actually half a mutex, so just a dedicated piece of API that can be useful for implementing Mutexes and many other components.

              Comment


              • #8
                Originally posted by LeJimster View Post
                So does this completely replace the Esync/Fsync implementations or is this something different? I would be interested to see what the real world differences with this new implementation are.
                Reality here with wine its been abusing fsync to emulating windows items that really don't own as a file operation.


                Yes esync is another form of abuse. This esync still file operations this time eventfd


                Both of these can cause you to run out of file handles.


                Your futex and futex2 are not file handle based. Yes the out of file handle problem wine suffers from with fsync/esync options will go away. Yes wine slow wineserver socket option of old did not suffer from the file handle problem but is just down right slow to to having process the locking in the wineserver process. Futex2 should give wine the application code path compatibility of the old wineserver option without the performance nightmare.

                Why could wine not use the old futex option simple you have wait on multi objects and other horrible things in windows that the old Linux futex does not handle well so resulting in performance killing code in wineserver.

                Yes fsync and esync are not designed to deal with NUMA issues. Yes the windows locking that wine has been attempting to emulate using fsync and esync and wineserver do have a NUMA part as well. Reality here is fsync and esync and old wineserver have really been round peg square hole as in partly works but its not quite right.

                The reality here is fsync and eventfd based syncs will not completely disappear out of wine as futex2 goes in instead will be used for what they are properly designed for not hacked for performance into being something they are not resulting in some odd ball application failures.

                Comment


                • #9
                  Originally posted by CochainComplex View Post
                  It can be already used by installing/compiling Xanmod kernel. https://xanmod.org/

                  as said by @akuthr its fsync.

                  If you are using Lutris just enable fsync.
                  Once your Wine Version (e.g. most recent Proton-GE) and your Kernel e.g. the Xanmod kernel have the latest patchset implemented in the Lustris Game log you will see that instead of "fsync up and running" "fsync2 up and running" will appear.
                  It's important to note here that XanMod is just one of many kernels that support fsync. If you're on an Arch based kernel, Zen Kernel is first party and will get you what you're looking for without much effort (Garuda Linux comes to mind). Liquorix is also available as binaries on Arch, Debian, and Ubuntu with different behavior/performance optimizations.

                  Comment


                  • #10
                    Originally posted by damentz View Post
                    Liquorix is also available as binaries on Arch, Debian, and Ubuntu with different behavior/performance optimizations.
                    I like how you throw Liquorix into the mix (see what I did there?) just for advertisement's sake!

                    Anyhow, now that MuQSS is history, will Liquorix come crawling back to CFS?

                    Comment

                    Working...
                    X