Date: Wed, 10 Jan 2007 09:45:13 -0500 From: Randall Stewart <rrs@cisco.com> To: Robert Watson <rwatson@freebsd.org> Cc: Craig Rodrigues <rodrigc@crodrigues.org>, freebsd-current@freebsd.org Subject: Re: Witness warning with SCTP Message-ID: <45A4FBF9.3040806@cisco.com> In-Reply-To: <20070110142100.G52843@fledge.watson.org> References: <20070107171034.GA13836@crodrigues.org> <45A139CF.3090909@cisco.com> <20070107185228.W41371@fledge.watson.org> <200701091426.36740.jhb@freebsd.org> <20070110142100.G52843@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Tue, 9 Jan 2007, John Baldwin 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.. Let me see.. R > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 <or> 803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45A4FBF9.3040806>