From owner-freebsd-current@FreeBSD.ORG Wed Jan 10 14:45:44 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 559C216A415; Wed, 10 Jan 2007 14:45:44 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.freebsd.org (Postfix) with ESMTP id 2E11713C43E; Wed, 10 Jan 2007 14:45:44 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 10 Jan 2007 06:45:43 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0AEjhLO016037; Wed, 10 Jan 2007 06:45:43 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0AEjh04024854; Wed, 10 Jan 2007 06:45:43 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 06:45:43 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 06:45:42 -0800 Message-ID: <45A4FBF9.3040806@cisco.com> Date: Wed, 10 Jan 2007 09:45:13 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Robert Watson References: <20070107171034.GA13836@crodrigues.org> <45A139CF.3090909@cisco.com> <20070107185228.W41371@fledge.watson.org> <200701091426.36740.jhb@freebsd.org> <20070110142100.G52843@fledge.watson.org> In-Reply-To: <20070110142100.G52843@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2007 14:45:43.0086 (UTC) FILETIME=[012724E0:01C734C6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1962; t=1168440343; x=1169304343; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Witness=20warning=20with=20SCTP |Sender:=20; bh=PsiEasm8cjczzme3j4MJAg8Kws36ekYANDIHIpuh/e4=; b=syTMNpJiQXBlmE/ZUzN4bOh4V/iQTX+sCFXW1TpQ/903ee1s0DoTRh776abP096XXzVSHxMa P3Be+FdtaPUjz4ZJOFL2HDGoVMBLL7vMn4PgiJ3JzrFMIzoNQUQ593xV; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); 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 14:45:44 -0000 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 803-317-4952 (cell)