Re: hi-res profiling

On Wednesday 02 October 2002 09.41, Robert Collins wrote:

> I came to the same conclusion from the source, and am glad to have
> it confirmed. For now, I agree with you on the timing of such
> recursion. I'm actually concerned about a much more complex case:
> something () {
> call cb function.
> }
>
> callback() {
> }

In which case you should generally stop the timer before making the
callback, but sure there is cases where it is hard to know.

Rule of thumb: Any probe spanning functions that may involve callbacks
back to ourselves must support nesting. I.e. If a probe is started by
the caller of something() above and left running when calling
something() then this probe must be a nesting/reentry capable type of
probe.

Local probes, i.e. probes started within something() do not need
nesting capabilities, and must be stopped on point of exit from
something(), where point of exit is defined as either return or
callback, whichever occurs first.

Global probes started by non-reentrable code such as a a probe running
from the comm_poll loop to measure the time spend on processing a
filedescriptor does not need to be reentrable/nesting capable. The
poll loop is not reentered via callbacks. There may be a huge amount
of callbacks going in within the called functions, but does not
matter, only callbacks going back to ourselves or our parents
matters.

Probes running while waiting for a callback is generally not
interesting in the type of probes implemented. Such probes need to be
dynamically created (preferably in the callback state data for the
function in question) as you may have any number of instances of it
"running" at the same time.

> where the callback occurs for a different instance of something().
> We need to be very sure to PROF_STOP (something) before calling out
> of it IMO.

If the probe is started in something, then it should be stopped as
soon as the control leaves something(). This is either at time of
callback

Regards
Henrik
Received on Wed Oct 02 2002 - 02:20:44 MDT