On Tue, Nov 06, 2012 at 10:46:24PM +0000, Russell King - ARM Linux wrote: > 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 It sources from 24 MHz crystal with a fixed divider 750, so it's 24000000 / 750 = 32000. Shawn > 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
