This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Controlling probe overhead
"Stone, Joshua I" <joshua.i.stone@intel.com> writes:
> [...] As a side note, we may need a better name to describe this --
> "accounting" is pretty vague, and "throttling" implies that we're
> holding back but not quitting (which would be cool, but much
> harder). Perhaps "cutoff" better describes what we're about here.
Or "overload". Throttling temporarily may not be that hard to do by
the way. One just needs a new state value that is different from
RUNNING. Probes may still be hit (and absorb quite some penalty), but
their handlers would return immediately.
> Right now I'm treating too much overhead as a hard error, but we
> could make it more like a forced exit instead. This way the end
> probes would still run, so if you have a long-running script that
> aborts suddenly due to overhead, you can still get some sort of
> report out of it. [...]
Another possibility is to leave it as a hard error, but introduce
"error" probes. It would be an end probe that runs iff we are exiting
in ERROR state: kind of between "end" and "never".
- FChE