Hi Amit, Santosh, On Thu, Sep 2, 2010 at 10:11 AM, Shilimkar, Santosh <santosh.shilimkar@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
