On 3/11/07, Robert Watson <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
