From owner-freebsd-arch@FreeBSD.ORG Tue Mar 13 10:01:46 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AFA716A401 for ; Tue, 13 Mar 2007 10:01:46 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2715E13C45A for ; Tue, 13 Mar 2007 10:01:45 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l2D9j5n1041641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2007 10:45:05 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l2D9j5be041639; Tue, 13 Mar 2007 10:45:05 +0100 (CET) Date: Tue, 13 Mar 2007 10:45:05 +0100 From: Divacky Roman To: LI Xin Message-ID: <20070313094505.GA40816@stud.fit.vutbr.cz> References: <45F2C2CB.5000204@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F2C2CB.5000204@delphij.net> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: MingyanGuo , freebsd-arch@freebsd.org Subject: Re: locking reasoning within fork1() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 10:01:46 -0000 > - The PID allocation is somewhat expensive when there are a lot of > processes. This might not be a very big deal, though, but given that it > requires to hold a sx_xlock, our scalability could be limited due to > this. tjr@ has a proposed hash based PID allocation patch in his p4 > branch, and NetBSD have an O(1) algorithm that may worth to have a look at. beside that.. what is RFHIGHPID good for? Its supposed to allocate pid > 10 which comment says its used during boot. But it only seems to be used for some kthreads (not all). No other BSD seems to use this... can we safely remove that? also.. would __predict_true/__predict_false usage help anything? netbsd seems to use it in their fork1() routine. especially the pid allocation could benefit from this.. comments? roman