Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Feb 2002 20:33:15 -0500 (EST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        smp@FreeBSD.org
Subject:   Re: Some thoughts on Giant instrumentation
Message-ID:  <XFMail.020228203315.jhb@FreeBSD.org>
In-Reply-To: <Pine.NEB.3.96L.1020228133307.70229E-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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 <jhb@FreeBSD.org>  <><  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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020228203315.jhb>