Re: Some thoughts on Giant instrumentation

: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.

    All I am advocating with Giant instrumentation is that when we have
    Giant in a particular place in the code and we believe it is safe to
    remove it, that instead of removing it we instrument it.  That's it.
    There is nothing complicated about it.  I think some people have blown
    Giant instrumentation completely out of proportion by trying to 
    over-engineer the concept I put forth.  

    Go back and look at the ucred patch I put forth two weeks ago (which 
    still hasn't been resolved).  All I did was to instrument Giant in
    a simple and straightforward way.

:s = giant_instrument(PROCLOCK_INST | PGRPLOCK_INST | ALLPROC_INST);
:
:Where the test can check to see if any of the particular instrumented bits

    The current implmentation works like this:

	s = mtx_lock_giant(some_sysctl_global);
	...
	mtx_unlock_giant(s).

    There is nothing preventing one from doing this:

	s = mtx_lock_giant(some_sysctl_global || some_other_sysctl_global);
	...
	mtx_unlock_giant(s).

    I am not adverse to changing the API slightly to make it possible to
    inline and conditionally compile the individual sysctl capabilities
    or to conditionally compile the entire procedure, but I do not feel
    any paricular need to do so at this time because the calls simply do 
    not eat up any significant amount of cpu.  I am not adverse to someone
    else doing the work, though.  As I told Peter, as long as it isn't
    turned into a mess of #define's he or someone else can conditionalize
    it.  An inline, a kernel option/#defined conditional compilation mask,
    and a bitmask would be heavily optimizable by GCC and an excellent
    solution.

						-Matt


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