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

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

 




> -----Original Message-----
> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Jean Pihet
> Sent: Friday, August 27, 2010 3:17 PM
> To: vishwanath.sripathy@xxxxxxxxxx
> Cc: linux-omap@xxxxxxxxxxxxxxx; linaro-dev@xxxxxxxxxxxxxxxx
> Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
> 
> Hi,
> 
> On Sat, Aug 28, 2010 at 12:08 AM,  <vishwanath.sripathy@xxxxxxxxxx> wrote:
> > From: Vishwanath BS <vishwanath.sripathy@xxxxxxxxxx>
> >
> > 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@xxxxxxxxxx>
> > Cc: linaro-dev@xxxxxxxxxxxxxxxx
> > ---
> ...
> 
> >
> > +#ifdef CONFIG_CPU_IDLE_PROF
> > +       sleep_time = omap3_sram_get_sleep_time();
> > +       wkup_time = omap3_sram_get_wkup_time();
> > +
> > +       /* take care of overflow */
> > +       if (postidle_time < preidle_time)
> > +               postidle_time += (u32) 0xffffffff;
> > +       if (wkup_time < sleep_time)
> > +               wkup_time += (u32) 0xffffffff;
> > +
> > +       idle_time = postidle_time - preidle_time;
> > +       total_sleep_time = wkup_time -  sleep_time;
> > +       latency = idle_time - total_sleep_time;
> > +       sleep_time = omap3_sram_get_sleep_time();
> > +       wkup_time = omap3_sram_get_wkup_time();
> Is it needed to re-read the sleep_time and wkup_time values from the scratchpad?

Sleep and wake up time stamps were taken just before and after executing wfi and stored in scratchpad wkup memory. These values are used while computing actual latency.

> What about the 32k timer overflow? Could that cause the sleep_latency
> and/or wkup_latency to be <0?
Overflow issues are taken care while computing idle_time and total_sleep_time in code below.
+       if (postidle_time < preidle_time)
 +               postidle_time += (u32) 0xffffffff;
 +       if (wkup_time < sleep_time)
 +               wkup_time += (u32) 0xffffffff;
> 
> > +
> > +       /* calculate average latency after ignoring sprious ones */
> > +       if ((total_sleep_time > 0) && (latency > state->actual_latency)
> > +               && (latency >= 0)) {
> > +               state->actual_latency = CONVERT_32K_USEC(latency);
> > +               latency = (sleep_time - preidle_time);
> Risk of overflow?
Yes I just realized that overflow can cause sleep_latency and wkup_latency to turn negative. Thanks for pointing it. Will fix it in next version. 
> 
> > +               state->sleep_latency = CONVERT_32K_USEC(latency);
> > +               latency = postidle_time - wkup_time;
> Risk of overflow?
Agreed. Will fix it. 

Vishwa
> 
> > +               state->wkup_latency = CONVERT_32K_USEC(latency);
> > +       }
> > +#endif
> > +
> >        return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
> >  }
> >
> 
> 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