On Thu, Dec 15, 2011 at 8:02 PM, john stultz <johns...@us.ibm.com> wrote:
> On Thu, 2011-12-15 at 14:06 +0100, Linus Walleij wrote:
>> It means that the kernel idea of sleep(1) is, sleep atleast 1 second,
>> possibly more. When the system scales down frequency, say to half
>> the frequency, things start to take twice the time. So sleep(1) may
>> result in 2 seconds of sleep or so.
>
> Just a minor clarification: So, while Linus is right that sleep can
> validly go longer then the requested time (the only promise is that it
> shouldn't return success early), sleep() should be timer based (not
> delay based), so even if the frequency drops, you *shouldn't* see freq
> proportional delays.

True. So what the three patches to the SMP_TWD is try to fix that
for the localtimers on these ARM systems, but sadly that doesn't
seem to cut it :-(

> If that were happening, it would seem timekeeping would also be slowed
> down, which def shouldn't happen if we're using a sane clocksource
> (although broken clocksources - which may change freq with the cpu -
> have caused symptoms like the above).

Yes skew in the clocksource would sort of affect the ruler that
you're using giving such phenomena.

The ux500 supports two different clock sources, so Daniel,
what happens if you just reactivate CPUfreq then use menuconfig
to go into drivers/ directly you will see the
"Clocksource PRCMU Timer" (sorry the clksrc subsystem does not
have its own submenu...), deselect that so as to use the
more monotone MTU clock source (it lives up in
arch/arm/plat-nomadik/timer.c by the way), what happens?

If that solves it, reactivate the PRCMU clock source and just
deselect the "clocksource PRCMU timer sched_clock"
and see what happens.

This way we can see if the PRCMU clock source is causing
it, or if it's simply caused by using the PRCMU for sched_clock
or if neither is causing it.

Yours,
Linus Walleij

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to