From: David Howells <dhowe...@redhat.com> Date: Tue, 08 Sep 2020 21:50:51 +0100
> Here are some development patches for AF_RXRPC that allow more simultaneous > calls to be made to the same peer with the same security parameters. The > current code allows a maximum of 4 simultaneous calls, which limits the afs > filesystem to that many simultaneous threads. This increases the limit to > 16. > > To make this work, the way client connections are limited has to be changed > (incoming call/connection limits are unaffected) as the current code > depends on queuing calls on a connection and then pushing the connection > through a queue. The limit is on the number of available connections. > > This is changed such that there's a limit[*] on the total number of calls > systemwide across all namespaces, but the limit on the number of client > connections is removed. > > Once a call is allowed to proceed, it finds a bundle of connections and > tries to grab a call slot. If there's a spare call slot, fine, otherwise > it will wait. If there's already a waiter, it will try to create another > connection in the bundle, unless the limit of 4 is reached (4 calls per > connection, giving 16). > > A number of things throttle someone trying to set up endless connections: > > - Calls that fail immediately have their conns deleted immediately, > > - Calls that don't fail immediately have to wait for a timeout, > > - Connections normally get automatically reaped if they haven't been used > for 2m, but this is sped up to 2s if the number of connections rises > over 900. This number is tunable by sysctl. > > > [*] Technically two limits - kernel sockets and userspace rxrpc sockets are > accounted separately. > > The patches are tagged here: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-next-20200908 Pulled, thanks David.
