Re: Some thoughts on Giant instrumentation

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 <[e-mail]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-smp" in the body of the message