On Thu, Dec 15, 2011 at 8:02 PM, john stultz johnstul@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