RE: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jean,

> -----Original Message-----
> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Jean Pihet
> Sent: Thursday, September 02, 2010 2:39 PM
> To: Shilimkar, Santosh
> Cc: Amit Kucheria; Kevin Hilman; linaro-dev@xxxxxxxxxxxxxxxx; linux-
> omap@xxxxxxxxxxxxxxx
> 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@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 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux