Jean,
-----Original Message----- From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- owner@vger.kernel.org] On Behalf Of Jean Pihet Sent: Thursday, September 02, 2010 2:39 PM To: Shilimkar, Santosh Cc: Amit Kucheria; Kevin Hilman; linaro-dev@lists.linaro.org; linux- omap@vger.kernel.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
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 did some profiling of assembly code on OMAP3630 board (ZOOM3). In worst case it takes around 3.28ms and best case around 2.93ms for mpu off mode. For MPU INACTIVE/RET, it is less than 30us. However as Kevin mentioned in other email, it would be better to find out a way to trace inside assembly code as well.
Regards Vishwa
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html