From owner-freebsd-current@FreeBSD.ORG Wed Jan 10 15:07:40 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A710416A403; Wed, 10 Jan 2007 15:07:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 503B513C459; Wed, 10 Jan 2007 15:07:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3DF984BC0C; Wed, 10 Jan 2007 10:07:36 -0500 (EST) Date: Wed, 10 Jan 2007 15:07:36 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Randall Stewart In-Reply-To: <45A4FBF9.3040806@cisco.com> Message-ID: <20070110150617.R52843@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> <45A4FBF9.3040806@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Craig Rodrigues , freebsd-current@freebsd.org Subject: Re: Witness warning with SCTP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 15:07:40 -0000 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