From owner-p4-projects@FreeBSD.ORG Mon Apr 24 22:04:07 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 131BC16A407; Mon, 24 Apr 2006 22:04:07 +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 BFBDE16A402; Mon, 24 Apr 2006 22:04:06 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43F6B43D46; Mon, 24 Apr 2006 22:04:06 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 95D5778C1D; Mon, 24 Apr 2006 22:04:05 +0000 (GMT) Date: Mon, 24 Apr 2006 22:04:05 +0000 From: John Birrell To: John Baldwin Message-ID: <20060424220405.GA62694@what-creek.com> References: <200604241913.k3OJDEAq055317@repoman.freebsd.org> <200604241637.08322.jhb@freebsd.org> <20060424213134.GA62456@what-creek.com> <200604241748.59461.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604241748.59461.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i 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 22:04:07 -0000 On Mon, Apr 24, 2006 at 05:48:58PM -0400, John Baldwin wrote: > 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. What I would like to do is have DTrace call a kern_linker function specifying a callback function that the linker would call for each module. The function needs to pass back an opaque argument, plus a pointer to the linker file structure. DTrace wants the module info not to change while it looks at the contents of the linker file structure. DTrace doesn't need to know how the modules are listed or locked, but it definitely needs to be able to allocate memory with wait while it is looking at the module data. > 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. I agree, but the structure of Sun's code does all it's allocations except the buffers with VM_SLEEP. It's a major rewrite of their code to fall back gracefully if memory isn't available. -- John Birrell