[PATCH] OMAP CPUIDLE: CPU Idle latency measurement
vishwanath.bs at ti.com
Tue Aug 31 05:58:41 BST 2010
> -----Original Message-----
> From: Silesh C V [mailto:saileshcv at gmail.com]
> Sent: Tuesday, August 31, 2010 9:53 AM
> To: Sripathy, Vishwanath
> Cc: Kevin Hilman; vishwanath.sripathy at linaro.org; linux-omap at vger.kernel.org;
> linaro-dev at lists.linaro.org
> Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
> Hi Vishwa,
> On Mon, Aug 30, 2010 at 6:29 PM, Sripathy, Vishwanath
> <vishwanath.bs at ti.com> wrote:
> > Kevin,
> >> -----Original Message-----
> >> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> >> owner at vger.kernel.org] On Behalf Of Kevin Hilman
> >> Sent: Saturday, August 28, 2010 12:45 AM
> >> To: vishwanath.sripathy at linaro.org
> >> Cc: linux-omap at vger.kernel.org; linaro-dev at lists.linaro.org
> >> Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
> >> vishwanath.sripathy at linaro.org writes:
> >> > From: Vishwanath BS <vishwanath.sripathy at linaro.org>
> >> >
> >> > This patch has instrumentation code for measuring latencies for
> >> > various CPUIdle C states for OMAP. Idea here is to capture the
> >> > timestamp at various phases of CPU Idle and then compute the sw
> >> > latency for various c states. For OMAP, 32k clock is chosen as
> >> > reference clock this as is an always on clock. wkup domain memory
> >> > (scratchpad memory) is used for storing timestamps. One can see the
> >> > worstcase latencies in below sysfs entries (after enabling
> >> > CONFIG_CPU_IDLE_PROF in .config). This information can be used to
> >> > correctly configure cpu idle latencies for various C states after
> >> > adding HW latencies for each of these sw latencies.
> >> > /sys/devices/system/cpu/cpu0/cpuidle/state<n>/actual_latency
> >> > /sys/devices/system/cpu/cpu0/cpuidle/state<n>/sleep_latency
> >> > /sys/devices/system/cpu/cpu0/cpuidle/state<n>/wkup_latency
> >> >
> >> > THis patch is tested on OMAP ZOOM3 using kevin's pm branch.
> >> >
> >> > Signed-off-by: Vishwanath BS <vishwanath.sripathy at linaro.org>
> >> > Cc: linaro-dev at lists.linaro.org
> >> While I have many problems with the implementation details, I won't go
> >> into them because in general this is the wrong direction for kernel
> >> instrumentation.
> >> This approach adds quite a bit overhead to the idle path itself. With
> >> all the reads/writes from/to the scratchpad(?) and all the multiplications
> >> and divides in every idle path, as well as the wait-for-idlest in both
> >> the sleep and resume paths. The additional overhead added is non trivial.
> >> Basically, I'd like get away from custom instrumentation and measurement
> >> coded inside the kernel itself. This kind of code never stops growing
> >> and morphing into ugliness, and rarely scales well when new SoCs are
> >> added.
> >> With ftrace/perf, we can add tracepoints at specific points and use
> >> external tools to extract and analyze the delays, latencys etc.
> >> 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.
> > The challenge here is that we need to take time stamp at the fag end of CPU Idle
> which means we have no access to DDR, MMU/Caches are disabled etc (on OMAP3).
> So I am not sure if we will be able to use ftrace/perf kind of tools here. If we choose
> to exclude assembly code part for measurement, then we will be omitting major
> contributor to CPU Idle latency namely ARM context save/restoration part.
> > Also these calculations are done only when we enable CPUIDLE profiling feature.
> > In the normal production system, these will not come into picture at all. So I am
> not sure latencies involved in these calculations are still an issue >when we are just
> doing profiling.
> There are two other issues when we use 32k timer for latency measurement.
> + /* take care of overflow */
> + if (postidle_time < preidle_time)
> + postidle_time += (u32) 0xffffffff;
> + if (wkup_time < sleep_time)
> + wkup_time += (u32) 0xffffffff;
> 1.We are checking postidle_time < preidle_time to find out whether
> there had been an
> over flow or not. There can be situations in which the timer
> overflows and still we have
> a greater postidle_time.
> 2. We are doing the correction for one overflow. What happens if the
> timer overflows for
> a second or third time. Can we keep track of the number of
> overflows and then do the
> correction accordingly?
Unfortunately, there is no way to check if overflow happens more than once in 32k timer and as you said, theoretically it's possible that if timer overflows more than once, these calculation will wrong. Having said that, do you really see any usecase where system will idle for more than 37 hours in single cpuidle execution to cause timer overflow?
> > Regards
> > Vishwa
> >> Kevin
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> >> the body of a message to majordomo at vger.kernel.org
> >> 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 at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linaro-dev