Date: Fri, 1 Mar 2002 00:20:10 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: John Baldwin <jhb@FreeBSD.ORG>, smp@FreeBSD.ORG Subject: Re: Some thoughts on Giant instrumentation Message-ID: <200203010820.g218KAF42627@apollo.backplane.com> References: <Pine.NEB.3.96L.1020228133307.70229E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 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?200203010820.g218KAF42627>