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_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 <or> 803-317-4952 (cell)Received on Wed Jan 10 2007 - 13:45:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC