Questions about (unstable) clocksources

[Paul Lussier]

Hi all,

I'm trying to understand the issues surrounding the recent (2.6.2[456])
troubles involving unstable clocksources.  Not being a kernel developer
I'm somewhat in the dark.  Also, if this isn't the correct forum to ask
these questions, please direct me to the proper place.  I have no wish
to clutter the channel with off-topic discussion.

My questions involve the characteristics and manifestations of the
problems as related to the clocksource when it becomes unstable (whether
it's tsc, hpet, acpi_pm, etc.)

I'm looking to understand these things:

 - When the clocksource goes unstable, what happens from a userspace
   perspective? i.e How will userspace processes percieve the problem?
   - Does time move at all?
   - If so, which way, forwards, backwards, either?
   - How can I detect this ?
     (size/magnitude of the delta reported in kern.log?)

 - If the TSC clocksource is registered unstable, and the another
   clocksource is chosen, can it too become unstable?
   - Based on the code in kernel/time/clocksource.c, it appears that
     clocksource_ratewd() will report the same basic message that any
     given clocksource is unstable.  Is that correct?

   - What causes hpet, acpi or jiffies to become unstable?
     (my understanding of the tsc issue is that it goes unstable in an
     SMP situation when it gets confused as to which CPU's ticks it's
     looking at.  What would cause the others to become unstable?

   - What happens if the next clocksource goes unstable?
     Does it just fallback to the next available clocksource?

And finally, what's the best way to avoid this problem (assuming a
default clocksource of tsc)?  Is it simply setting clocksource=hpet in
my grub config file?  Are there other kernel options I ought to
consider?  I've seen some mention of setting nohz=off, but no
explanation as to why that helps.

Thanks,
-- 
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/