Announcement

Collapse
No announcement yet.

Linux 5.17 To Boast Latency Optimization For AF_UNIX Sockets

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

  • Linux 5.17 To Boast Latency Optimization For AF_UNIX Sockets

    Phoronix: Linux 5.17 To Boast Latency Optimization For AF_UNIX Sockets

    Net-next has been queuing a number of enticing performance optimizations ahead of the Linux 5.17 merge window kicking off around the start of the new year. Covered already was a big TCP optimization and a big improvement for csum_partial() that is used in the network code for checksum computation. The latest optimization is improving the AF_UNIX code path for those using AF_UNIX sockets for local inter-process communication...

    https://www.phoronix.com/scan.php?pa...X-Optimization

  • #2
    What does "count" stand for?

    Comment


    • #3
      Originally posted by cl333r View Post
      What does "count" stand for?
      The data presented appear to be histograms. So, the `count` would be the number of cases where latency fell within the range corresponding to that bin.

      Comment


      • #4
        This seems to be a nice improvement, with majority of functions() concentrated in the lowest scale of latency..
        I like particularly of the [0-3500] nsec, and [0-14] usec
        tuxd3v
        Senior Member
        Last edited by tuxd3v; 28 November 2021, 02:20 PM.

        Comment


        • #5
          Would also be interesting to test a equivalent version of AF_INET..

          Comment


          • #6
            I wonder how unix sockets compare to a loopback TCP socket; I wouldn't be surprised if they are slower, due to neglect.

            Comment


            • #7
              Originally posted by microcode View Post
              I wonder how unix sockets compare to a loopback TCP socket; I wouldn't be surprised if they are slower, due to neglect.
              Writing a similar benchmark shouldn't be particularly hard. I *could* get away with using a high core count AWS instance paid by my employer for a very short while, but I doubt I'll put the time.

              Originally posted by tuxd3v View Post
              Would also be interesting to test a equivalent version of AF_INET..
              Assuming we have a similar hash table with a shared lock for the whole table.

              Originally posted by tildearrow
              That's amazing. It should help everything from X11?Wayland to PulseAudio.
              It depends. This is only useful when you have many open sockets, as that's when contention around the shared lock increases. A lock that's pretty much always available because you have few open sockets adds almost no latency.

              Comment


              • #8
                Originally posted by tildearrow
                That's amazing. It should help everything from X11?Wayland to PulseAudio.
                No. This is just about creating the socket, bind and connect. The patches improves latency of creating the socket, under big contention (i.e. hundredths of sockets created per second from multiple CPUs).

                Once the socket is created and bound, the performance will be the same (the data path for already created sockets is already highly scalable, and does not use global locks).

                It is a niche use case (i.e. connecting to local databases for short duration queries), but better scalability is always welcome.

                Comment


                • #9
                  Originally posted by microcode View Post
                  I wonder how unix sockets compare to a loopback TCP socket; I wouldn't be surprised if they are slower, due to neglect.
                  Quick test with lmbench on my 5.11:

                  Code:
                  AF_UNIX sock stream latency: 7.0597 microseconds
                  UDP latency using localhost: 8.8534 microseconds
                  TCP latency using localhost: 10.4962 microseconds
                  
                  AF_UNIX sock stream bandwidth: 6675.49 MB/sec
                  TCP stream bandwidth: 5020.23 MB/sec

                  Comment


                  • #10
                    Originally posted by baryluk View Post
                    It is a niche use case (i.e. connecting to local databases for short duration queries), but better scalability is always welcome.
                    its not a niche, because some databases, at least big ones use and abuse of it.. so for business , its a good thing..
                    Agree improvements are always better..

                    Comment

                    Working...
                    X