From owner-freebsd-smp Thu Feb 28 17:34: 4 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 275E137B402 for ; Thu, 28 Feb 2002 17:33:50 -0800 (PST) Received: (qmail 3225 invoked from network); 1 Mar 2002 01:33:46 -0000 Received: from unknown (HELO server.baldwin.cx) ([65.91.152.157]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Mar 2002 01:33:46 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g211XMG42462; Thu, 28 Feb 2002 20:33:22 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 28 Feb 2002 20:33:15 -0500 (EST) From: John Baldwin To: Robert Watson Subject: Re: Some thoughts on Giant instrumentation Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 28-Feb-02 Robert Watson wrote: > > I'm not opposed to the idea of instrumentation, although that's probably > simply that so far we haven't managed to shoot ourselves quite enough to > have me wish I had it. One of my concerns with instrumentation has always > been the fine-grained issue: throwing Giant back into the mix will change > a fair amount about the codepath, and that if we adopt a phased locking of > a large structure (proc, for example), then we don't have all that much > granularity, suggesting that we'll probably want to look at something that > has more complexity than the current scheme. > > One of my particular concerns has been regarding the following: suppose a > structure is covered by three or four relevant locks. We decide to > selectively instrument one of those sets of locks (perhaps because we just > added it, having determined the others are stable). do we want to be able > to say: > > s = giant_instrument(PROCLOCK_INST | PGRPLOCK_INST | ALLPROC_INST); Yes. That is why in my example I had a syscall protected by "proc,vfs" meaning that both the proc variable and the vfs variable would be checked. > Where the test can check to see if any of the particular instrumented bits > of the mask require Giant, and then DTRT? This would help somewhat with > the "collapse the instrumentation" some, assuming the simplification that > we don't do too much instrumentation below the system call where it gets > complex. Which appears to be something we should avoid doing anyway so > that Giant doesn't end up in the wrong place in the lock order. *nod* This is pretty much what I said. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message