tiomap-dev team mailing list archive

[Ricardo Salveti <rsalveti@xxxxxxxxxxxx>]

On Thu, Dec 1, 2011 at 11:59 PM, warmcat <873453@xxxxxxxxxxxxxxxxxx> wrote:
> I'm sorry Ricardo I meant CPU_IDLE.  I think this bug is old enough
> originally to predate us enabling CPU_FREQ.  But we had CPU_IDLE on for
> a while before that.
>
> We are anyway looking at CPU_IDLE implementation we have because we
> found it never moves away from the first C-state even though it is
> definitely getting called and acting otherwise reasonable.  In addition
> there were big changes in 3.2-rc1 / rc2 about cpuidle api which I
> updated in our tracking.  They did change how they accounted for time
> while idle.
>
> So it'd be interesting to see if the issue can be reproduced with
> CPU_IDLE disabled if it is currently enabled.  If it's not currently
> enabled, well, I dunno.

It's also enabled with current kernel:
linaro@linaro-ubuntu-desktop:~$ grep CPU_IDLE= /boot/config-3.1.0-140*
/boot/config-3.1.0-1400-linaro-lt-omap:CONFIG_CPU_IDLE=y
/boot/config-3.1.0-1401-linaro-lt-omap:CONFIG_CPU_IDLE=y
/boot/config-3.1.0-1402-linaro-lt-omap:CONFIG_CPU_IDLE=y

Will recompile the kernel without CPU_IDLE and post the link to the
bug in a few minutes.

-- 
You received this bug notification because you are a member of TI OMAP
Developers, which is subscribed to linaro-landing-team-ti.
https://bugs.launchpad.net/bugs/873453

Title:
  odd timing behaviour on panda

Status in Linaro Texas Instruments Landing Team:
  New
Status in Linaro Ubuntu Evaluation Builds:
  New

Bug description:
  I've got a set of benchmarks that use clock_gettime like:

      clock_gettime(CLOCK_REALTIME, &tbefore);

      for(l=0;l<numloops;l++) {
         dostuff
      }

      clock_gettime(CLOCK_REALTIME, &tafter);

      nsdiff=(double)(tafter.tv_nsec - tbefore.tv_nsec);
      nsdiff+=1000000000.0 *(tafter.tv_sec - tbefore.tv_sec);

  
  and I've just reinstalled our local panda to using Linaro 11.09 (kernel 3.0.0-1404-linaro-lt-omap)
  and it's starting to get weird timing artifacts.

  For example:

  smarter_strlen_ldrd: ,102400, loops of ,62, bytes=6.054688 MB, transferred in ,3936768.000000 ns, giving, 1537.984331 MB/s
  smarter_strlen_ldrd: ,102400, loops of ,32, bytes=3.125000 MB, transferred in ,0.000000 ns, giving, inf MB/s
  smarter_strlen_ldrd: ,102400, loops of ,16, bytes=1.562500 MB, transferred in ,4180909.000000 ns, giving, 373.722557 MB/s

  Now there is no way that loop took 0.000000 ns!  Running the same
  binary on an older installation runs fine.

  Dave

To manage notifications about this bug go to:
https://bugs.launchpad.net/linaro-landing-team-ti/+bug/873453/+subscriptions