Witness warning with SCTP

[Randall Stewart]

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)