This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]