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