Linux 5.17 To Boast Latency Optimization For AF_UNIX Sockets

[phoronix]

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?page=news_item&px=Linux-5.17-AF_UNIX-Optimization

[cl333r]

What does "count" stand for?

[coder]

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.

[tuxd3v]

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]

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

[microcode]

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

[sinepgib]

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.

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.

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.

[baryluk]

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.

[F.Ultra]

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:

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

[tuxd3v]

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