Date: Mon, 19 Mar 2007 15:54:55 -0400 From: "Keith Arner" <vornum@gmail.com> To: "Robert Watson" <rwatson@freebsd.org> Cc: net@freebsd.org Subject: Re: netisr_direct Message-ID: <8e552a500703191254qba4e194y810eb99a9f07bed8@mail.gmail.com> In-Reply-To: <20070311073249.R20646@fledge.watson.org> References: <45C0CA5D.5090903@incunabulum.net> <45E6BEE0.2050307@FreeBSD.org> <45E6C22D.7060200@freebsd.org> <45E6D70C.10104@FreeBSD.org> <45EEB086.3050409@FreeBSD.org> <45F03269.7050705@FreeBSD.org> <45F08F1D.5080708@us.fujitsu.com> <20070310035135.B30274@fledge.watson.org> <8e552a500703102157p1845926au65bb3adaf81c01c0@mail.gmail.com> <20070311073249.R20646@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/11/07, Robert Watson <rwatson@freebsd.org> wrote: > > > There are several ways we could start to reduce contention on that lock: > > (3) Move towards greater granularity of locking for the tcbinfo: instead > of > a single mutex, move to more than one locks, so that different > connections > processed simultaneously are likely to involve different locks. For > listen sockets, we would have to have a special case, such as a > single > lock to serialize simultaneous lock acquisitions of multiple chain > locks > (for example). > I've been thinking about this approach, and it does sound like the simplest to implement of the three proposed. However, the special case of the listen socket seems like it would complicate matters. It seems to me, however, that the complication of the listen socket could be simplified if the listen sockets were maintained in a separate pcb list from the rest of the TCP sockets (the fully connected sockets). If the two types of sockets were thus separated, the code would acquire the lock on the bucket in the connect hash, and search the connect hash; if there was a miss, acquire the lock on the listen list and then search the listen list. The lock on the listen list should follow the locks on the connect buckets in the locking order. The connection bucket should be locked first, as delivery of data would be the common case. To create a new connection in the tcp_input path, both the connect bucket and the listen list would need to be locked (connect bucket as a new entry would be added to the list, and listen list as the accept socket would be protected from going away). Keith
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8e552a500703191254qba4e194y810eb99a9f07bed8>