Date: Wed, 10 Jan 2007 15:07:36 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Randall Stewart <rrs@cisco.com> Cc: Craig Rodrigues <rodrigc@crodrigues.org>, freebsd-current@freebsd.org Subject: Re: Witness warning with SCTP Message-ID: <20070110150617.R52843@fledge.watson.org> In-Reply-To: <45A4FBF9.3040806@cisco.com> References: <20070107171034.GA13836@crodrigues.org> <45A139CF.3090909@cisco.com> <20070107185228.W41371@fledge.watson.org> <200701091426.36740.jhb@freebsd.org> <20070110142100.G52843@fledge.watson.org> <45A4FBF9.3040806@cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Jan 2007, Randall Stewart wrote: >>> Either that or use an sx lock to close the pcb alloc race instead and >>> don't hold mutexes while calling hashinit(). >> >> I think this is a good point -- I've generally been restructuring PCB init >> functions so that they perform allocation up front before acquiring locks >> in order to reduce lock contention on the table locks, which are global and >> acquired in many other paths. This tends to simplify error handling also. >> I'm not sure how well that applies in this case, however. Certainly, we >> want to optimize for successful handling, since malloc(9) failure is very >> unusual and occurs only in very exceptional (and unfortunate) cases. A >> more likely failure is the exhaustion of the zone limit on the pcb zone, >> which gates the overall allocation of memory for the socket type, and >> should be the first memory type allocated when setting up pcbs for this >> reason. > > There are checks way up front on getting the pcb memory... > > I don't think I would want to convert these to sx_locks since according to > the manual page : > > " Shared/exclusive locks are used to protect data that are read far more > often than they are written. Mutexes are inherently more efficient than > shared/exclusive locks, so shared/exclusive locks should be used pru- > dently. " > > And the lock in question is used a lot... (protecting the pcb).. > > Hmm.. maybe I can restructure things to pre-alloc the memory before the > locks.. As a general rule, sx locks are not appropriate for use in the "in-bound" portions of the network stack, although the sleeping socket locks serializing socket I/O operations in socket consumers are functionally similar. Normally only mutexes and rwlocks should be used in low level bits of the stack, as they may well be acquired in ithread or swi contexts where the unbounded sleep primitives used in sx locks are not appropriate. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070110150617.R52843>