scheduler clock for MXS

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Tue, Nov 06, 2012 at 11:30:44PM +0100, Stanislav Meduna wrote:
> On 06.11.2012 21:20, Russell King - ARM Linux wrote:
> > Well.  I just tried an experiment with OMAP4:
> > [    0.000000] sched_clock: 16 bits at 32kHz, resolution 30517ns,
> wraps every 1999ms
> > ...
> > [    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?