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? -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
