tiomap-dev team mailing list archive

[warmcat <873453@xxxxxxxxxxxxxxxxxx>]

Ricardo I think you might find if you do

# echo performance >
/sys/devices/system/cpu/cpu0/cpu0/cpufreq/scaling_governor

in 4460 case, after the rootfs forced it to ondemand, you will only see
problems periodically when the thermal_framework stuff kicks in, a
different pattern of behaviour.

David, I don't know what caused these problems historically, but I think
what's left with tracking is that the issue is coming from 4460-specific
cpufreq change action.  I think on tracking, for 4430 it's OK.

Dave, I think it's worth reviewing that code you already know from the
4460 clock rounding / changing patch you did (I don't mean your patch, I
mean the flow around that code) looking for ways it could screw with
timekeeping.  We already know at least the version of that code we had
didn't have all the critical bugs shaken out of it by the time we got
it.  Maybe also review Keerthy's cpu temp sensor driver you also know
well now since that's also 4460 specific.

-- 
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:
  Confirmed
Status in Linaro Ubuntu Evaluation Builds:
  Confirmed

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