Controlling probe overhead

[David Smith]

I've attached yet another version of the patch.  I've renamed this to be 
"overload" processing (as Frank suggested in another email).  See 
comments below.

Stone, Joshua I wrote:
> David Smith wrote:
>> Making exceptions for begin/end probe is going to be a bit difficult,
>> since the common_probe_entryfn_prologue() and
>> common_probe_entryfn_epilogue() functions don't really have any
>> context of where they are called from.
> 
> It's simple to add that context -- we can add a parameter to those
> functions so that the default does output the throttling checks, and
> then modify the call site in be_derived_probe_group::emit_module_decls()
> to turn them off.

Yep, you were right, it wasn't hard at all to add that context.  Done.

>> Besides sharing code with STP_TIMING, I also added a command-line
>> switch to turn this new functionality off (but your idea of tunable
>> thresholds is probably better).

BTW, I had to rework the STP_TIMING code a very small bit to make it 
work correctly with the STP_OVERLOAD code.  The STP_TIMING code was 
storing cycle counts as 32-bit values, where the STP_OVERLOAD code 
wanted 64-bit cycle counts.  The STP_TIMING code now truncates down to 
32-bits a little later than it did originally.

> An option to disable it is a good idea.  As for tuning the threshold, we
> could make a new -D option like MAXOVERHEAD.  If this is a percentage,
> then internally we can just define this:
> 
> #define STP_ACCOUNTING_THRESHOLD
> MAX_OVERHEAD*STP_ACCOUNTING_INTERVAL/100
> 
> This way we expose some control without exposing the implementation of
> the threshold and interval.

With the attached patch, you can tune (using "stap -D") both the 
INTERVAL and the THRESHOLD.  I didn't implement your above idea of 
MAX_OVERHEAD (although it is certainly doable).

I've been testing with the attached patch, and it works very nicely for 
me.  I can run the test suite with no interference from the OVERLOAD 
stuff.  I've run several stress tests with no interference from the 
OVERLOAD stuff.  I've have one stress test (that Frank wrote) that will 
make a RHEL5 system non-responsive.  The system doesn't crash - just 
decides to no longer take any input.  The overload code kills the script 
in less than 3 minutes.

Note that I haven't implemented the new error probes you and Frank 
discussed.  I'd like to get the current code in (since it is quite 
useful in its current state) before thinking about error probes.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stp_overload.patch
Type: text/x-patch
Size: 8460 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20070314/cfc8ae83/attachment.bin>