On Tue, Nov 06, 2012 at 11:30:44PM +0100, Stanislav Meduna wrote:

On 06.11.2012 21:20, Russell King - ARM Linux wrote:

quoted

Well.  I just tried an experiment with OMAP4:
[    0.000000] sched_clock: 16 bits at 32kHz, resolution 30517ns,

wraps every 1999ms

quoted

...
[    3.070404] Freeing init memory: 192K

OK, so it is not a 16-bit problem either. So where is the
difference? Could it be that HZ / NO_HZ is playing some
tricks here and need to be taken into consideration?

I'll try to artificially limit the counter-reading function
on my hardware to 16 bits and look whether I can also
reproduce this - probably on Thursday or Friday earliest
(busy with other tasks now).

If it works I'll resubmit for only the iMX.28 and someone
who actually has the iMX.23 hardware to experiment with has
to look at it; the best start is probably to start with
comparing it to the working OMAP4. If it does not I'll
try to find the culprit.

I wonder if the NO_HZ slack is preventing the sched_clock epoch update
from happening in time.  Hmm.

 * round_jiffies - function to round jiffies to a full second

This is probably it.  With mine, it's a 32.768kHz clock, so limiting
it to 16-bit gives a wrap period of 2 seconds exactly.  We take 10%
off, so the timer would be asked to fire every 1.8s, which would be
rounded up to 2 seconds.  That's a little too close for comfort...

Yours on the other hand:

sched_clock: 16 bits at 32kHz, resolution 31250ns, wraps every 2047ms

says that this timer runs at _exactly_ 32kHz (are you sure?  If this is
generated from a separate 32k crystal oscilator, it's most likely
32.768kHz because that's the standard crystal frequency.  In any case,
this would give a wrap period of just over 2 seconds.

But remember, we take of 10%, so this would give 1843ms.  Jiffy
conversion would give 185 jiffies, and rounded up to a second gives
200 jiffies, so again 2 seconds.

I suspect that your timer _does_ run at approximately 32768kHz, meaning
that it _does_ roll over at 2 second intervals.  But maybe it's trimmed
to be slightly fast or maybe your kernel's idea of time is slightly
slow - either one of which would then give you this effect.

However, either way, rounding 1.8s up to 2s for a 16-bit 32768kHz
counter isn't going to give reliable results.

I think in this case, we need a version of round_jiffies() which _always_
rounds down.  Unfortunately, it doesn't exist.  Thomas?  What are the
options here?