Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Jan 2007 14:22:56 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Craig Rodrigues <rodrigc@crodrigues.org>, Randall Stewart <rrs@cisco.com>, freebsd-current@freebsd.org
Subject:   Re: Witness warning with SCTP
Message-ID:  <20070110142100.G52843@fledge.watson.org>
In-Reply-To: <200701091426.36740.jhb@freebsd.org>
References:  <20070107171034.GA13836@crodrigues.org> <45A139CF.3090909@cisco.com> <20070107185228.W41371@fledge.watson.org> <200701091426.36740.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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.

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?20070110142100.G52843>