[Avrora] Trip Time Monitor

[Ben L. Titzer]

On Dec 6, 2005, at 4:32 PM, Ram Kumar Rengaswamy wrote:

> Hi,
>      Thanks for the clarification about the interrupt monitors. I  
> have a couple of questions about the trip-time monitor.
>
> 1. What happens if an interrupt arrives when the program is  
> executing between a pair of addresses whose trip time I am  
> interested in measuring ?
>     Does the trip-time monitor also add the interrupt service  
> routine overhead to the trip time ?
>

The interrupt service routine latency will be included. This is  
because the trip time monitor only inserts probes at the endpoints  
and does not care what code is executed in-between.

> 2. I have a subroutine with multiple rets. What would be the  
> correct way to profile the execution time of this subroutine ? I am  
> currently passing a list of pairs as follows:
>  -pairs=<sub_start>:<ret#1>,<sub_start>:<ret#2>
>

With the trip time monitor, I don't think this will result in correct  
behavior because it assumes that each pair has a unique exit point;  
i.e. when you enter at the start address, it will "activate" a new  
interval for both of the pairs, and when the code reaches either of  
the endpoints, it will deactivate the corresponding interval, while  
leaving the other interval "still running"--thus you will get  
incorrect results.

To solve problems 1 and 2 I think that the only way you can solve  
these problems is to write some custom instrumentation by using the  
the trip-time and interrupt monitors as a guide.

For example, to solve the first problem, you need to instrument  
interrupt invocations in order to subtract out the interrupt service  
time from the underlying computation it interrupts, and for the  
second problem, you need to have one entrypoint (interval enabler)  
and multiple exit point (interval disabler) probes. This is more  
along the lines of the stack-based method of the call monitor.

You should look at the call monitor for inspiration; you can do a  
similar type of stack-based approach, but instead of simply printing  
out the calls and returns, collect statistics. You could even add  
this functionality to the existing call monitor and provide options  
to enable or disable it.

By the way, I have wanted to implement this type of instrumentation  
for some time, but I could never muster the time. Up until now no one  
has recognized the need. I think that you should be able to do it  
without much trouble.

If you come up with some useful functionality I will happily accept a  
patch to put into the mainline branch.

> Thanks,
> -Ram
>
> _______________________________________________
> Avrora mailing list
> Avrora at lists.ucla.edu
> http://lists.ucla.edu/cgi-bin/mailman/listinfo/avrora

========================================================
One machine can do the work of fifty ordinary men. No machine can do  
the work of one extraordinary man.
--Elbert Hubbard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucla.edu/pipermail/avrora/attachments/20051206/8ffd1ee7/attachment.htm