Controlling probe overhead

David Smith dsmith@redhat.com
Thu Mar 15 13:19:00 GMT 2007


Stone, Joshua I wrote:
> Frank Ch. Eigler wrote:
>>>       cycles_t interval = (cycles_atend > c->cycles_base)
>>>         ? (cycles_atend - c->cycles_base)
>>>         : (STP_OVERLOAD_INTERVAL + 1);
>> BTW right here is where it will break if the actual hardware counter
>> is narrower than cycles_t.  If cycles_base was set near its overflow
>> point (which may be much less than 2**63), then even a brief probe
>> will end up with a cycles_atend < cycles_base.  That in turn would
>> lead to an erroneous overload indication.
> 
> It will generate an extra threshold comparison, but the error indication
> only occurs if cycles_sum is more than THRESHOLD.  This "quick-wrap"
> scenario will be a wasted check, since the sum won't have accumulated
> much.  However, if there's a real problem, it will be caught on the
> following interval.

Josh is right, I'm just basically forcing cycles_sum/cycles_base to get 
reset if we've wrapped.

Josh explained this better in a previous email, but the INTERVAL just 
tells us how often to check cycles_sum.  If in that INTERVAL cycles_sum 
has passed the THRESHOLD, then we've overloaded the system and need to quit.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)



More information about the Systemtap mailing list