Announcement

Collapse
No announcement yet.

FUTEX2 Linux Patches Updated To Support Variable-Sized Futexes

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

  • FUTEX2 Linux Patches Updated To Support Variable-Sized Futexes

    Phoronix: FUTEX2 Linux Patches Updated To Support Variable-Sized Futexes

    One of the elusive kernel patch series we have been eager to see for the mainline Linux kernel has just been spun up a fourth time...

    https://www.phoronix.com/scan.php?pa...System-Call-v4

  • #2
    I'm still waiting for the proper NTFS support, but it would be nice if at least this would get in.

    Comment


    • #3
      Originally posted by Danny3 View Post
      I'm still waiting for the proper NTFS support, but it would be nice if at least this would get in.
      The problem is that there are few use cases for NTFS on Linux. Mainly it's just for dual boot machines and those are rare now. Which means merging in NTFS improvements is bound to remain a low priority.

      Comment


      • #4
        Originally posted by jacob View Post
        Mainly it's just for dual boot machines and those are rare now.
        They are?

        Comment


        • #5
          Originally posted by aufkrawall View Post
          They are?
          With the generalisation of virtualisation (working both ways), the massive improvements in Wine and the advent of WSL(2), yeah, I see them once in a blue moon now. There was a time when a dual boot option was front and center in all major distros' installers, now in many cases it's barely even documented.

          Comment


          • #6
            Although kernel engineers seemed to acknowledge that improvements can be made in general and in theory, in comments to previous patch versions I didn't have the impression that they are anywhere close to accepting this series of patches, on the contrary.

            So I think 5.14 is completely unrealistic, the question would be more if ever.

            I checkd on the numbers given for speed improvement. These were 4% on benchmarks for operations that, as far as I can tell based on the limited information I could see, take about up to 850 ns (futex-wait perf test on my system). The claim seemed to be that some games execute 40,000 to 50,000 futex operations per second, and I don't know better than to assume it is these ~850ns operations. That would be an improvement of 1.7ms per second, which for a 200 fps game woudn't even be 1 fps.

            Of course this is somewhat speculating about the meaning of these numbers, but that is my point: no clear argument has been made.

            Keep in mind that this would be the improvement compared to the existing futex implementation. The existing futex implementation could still be used to make WINE *much* faster than WINE's current implementation using fsevents, esync or whatever.

            Also, if performance is the goal and if it would actually matter for these operations, I believe there are much better ways to get optimal performance if creating a new "system" would really be on the table. These would not have to create more burden on the kernel, but could remove burden from the kernel.

            Last but not least, this specific wait multiple futex concept here seems to be designed to support a (Windows-) API that is broken, partially deprecated and otherwise anything else than optimal or great, and lacks functionality that it should have.

            Comment


            • #7
              Originally posted by Danny3 View Post
              I'm still waiting for the proper NTFS support, but it would be nice if at least this would get in.
              Speaking of NTFS, has the Paragon proposed NTFS driver been queued in 5.13 ? https://www.phoronix.com/scan.php?pa...FS3-v22-Driver

              Comment


              • #8
                Originally posted by indepe View Post
                I checkd on the numbers given for speed improvement. These were 4% on benchmarks for operations that, as far as I can tell based on the limited information I could see, take about up to 850 ns (futex-wait perf test on my system). The claim seemed to be that some games execute 40,000 to 50,000 futex operations per second, and I don't know better than to assume it is these ~850ns operations. That would be an improvement of 1.7ms per second, which for a 200 fps game woudn't even be 1 fps.
                For different client side anti-cheat system that windows programs have its more than enough to be the difference between allow the player and ban the player.

                Originally posted by indepe View Post
                Last but not least, this specific wait multiple futex concept here seems to be designed to support a (Windows-) API that is broken, partially deprecated
                This is unfortunate not true to look at as deprecated. WaitMultipleObjects from Windows API is not deprecated and common used in games. The WaitMultipleObjects function only comes into existence with windows XP/2003. There is a older signal system that is deprecated by WaitMultipleObjects function that waws also used to wait for multiple objects.

                How to solve the wait on multiple is own problem.

                Comment


                • #9
                  Awesome. Using 32bit futex on 64bit std::atomic bit us in surprising ways.

                  Comment


                  • #10
                    Originally posted by xxmitsu View Post

                    Speaking of NTFS, has the Paragon proposed NTFS driver been queued in 5.13 ? https://www.phoronix.com/scan.php?pa...FS3-v22-Driver
                    Patchset 26 was released a couple months ago. Doesn't seem like it has too much more work to do.

                    https://lore.kernel.org/lkml/2021040...-software.com/

                    Comment

                    Working...
                    X