Hi Amit, Santosh,
On Thu, Sep 2, 2010 at 10:11 AM, Shilimkar, Santosh santosh.shilimkar@ti.com wrote: ...
The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel.
Kevin,
I agree. We discussed this a little in our weekly meeting. Vishwa's main concern was the lack of ability to instrument the last bit of SRAM code.
I have a feeling that even with caches on when we enter this code, we won't see too much variance in the latency to execute this bit of code. Vishwa is going to confirm that now. If that hypothesis is true, we can indeed move to using tracepoints in the idle path and use external tools to track latency.
I agree. Can you confirm this asap? I am looking at the instrumentation tracepoints now. I think it would be ideal to provide multiple tracepoints in both sleep and wake-up paths.
There will be difference with and without caches but the delta latency will be constant with caches and without caches. Another important point is he lowest level code should be just profiled once and for worst CPU/BUS clock speed.
Ok.
Even if it isn't true, the rest of the idle path could still contain tracepoints.
I am looking at the best way to introduce tracepoints in the low level code, in case it is needed.
I also think this would be better approach considering a generic solution.
Good!
Regards, Santosh
Jean