From owner-p4-projects@FreeBSD.ORG Mon Apr 24 21:49:11 2006 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 1231616A412; Mon, 24 Apr 2006 21:49:11 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C629916A405 for ; Mon, 24 Apr 2006 21:49:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 461CF43D69 for ; Mon, 24 Apr 2006 21:49:08 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k3OLn7NY055407; Mon, 24 Apr 2006 17:49:07 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: John Birrell Date: Mon, 24 Apr 2006 17:48:58 -0400 User-Agent: KMail/1.9.1 References: <200604241913.k3OJDEAq055317@repoman.freebsd.org> <200604241637.08322.jhb@freebsd.org> <20060424213134.GA62456@what-creek.com> In-Reply-To: <20060424213134.GA62456@what-creek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604241748.59461.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1424/Mon Apr 24 10:39:06 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Perforce Change Reviews Subject: Re: PERFORCE change 96007 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 21:49:11 -0000 On Monday 24 April 2006 17:31, John Birrell wrote: > On Mon, Apr 24, 2006 at 04:37:07PM -0400, John Baldwin wrote: > > On Monday 24 April 2006 15:13, John Birrell wrote: > > > ASSERT(MUTEX_HELD(&dtrace_lock)); > > > - for (i = 0; i < mp_ncpus; i++) { > > > + for (i = 0; i < mp_maxid; i++) { > > > > Use <= with mp_maxid. The range is 0 .. mp_maxid (inclusive). > > > > Yeah I see that now, thanks. I've weeded out mp_ncpus. > > What I really need to do is to use the cpu list and only allocate > buffers for the cpus that exist. That's what Solaris does. I'm > not sure what the locking issues are with doing that. Typically one does: for (i = 0; i <= mp_maxid; i++) { if (CPU_ABSENT(i)) continue; ... } > DTrace also needs to go through the module list and it wants > to hold a lock on that, but also allocate memory with wait. > > So what I really need is a version of the sx lock which is > recursive for exclusive locks. > > Then I need to change the kern/kern_linker.c code to use that > sort of lock, not just a mutex. > > Any thoughts on that? 1) I've already completely redone all of the locking in the kernel linker to use a big sx lock around the whole kernel linker. I have to tidy up some issues with ndis still. 2) Tell me what dtrace is trying to do and let's see if we can provide an API hook in the kernel linker for it instead of having DTrace grovel around in the linker's internals. Then DTrace doesn't need to be aware of any locking for the kernel linker. 3) Generally speaking it is better (if possible) to preallocate resources before acquiring a lock so that you don't hold the lock as long. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org