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
