Re: Ktimer / -rt9 (+custom) monotonic_clock going backwards.

[Ingo Molnar <mingo@elte.hu>]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> > Last night I just caught a bug I accidentally introduced with the fixed
> > interval math (oh, if only optimizations didn't dirty code so!), where
> > time inconsistencies were possible when clocksources were changed. I'm
> > not sure if that's the issue being seen above, but I'll wrap things up
> > and send out a B8 release today if I can.
> 
> Hmm, I believe that the ktimers use the apic (when available) and let 
> the jiffies still be calculated via PIT/TSC.
> 
> Thomas, is the above correct?
> 
> Would that have triggered your bug?

if the bug is only possible when timesources are changed on the fly, 
then i think it shouldnt happen. We pick our sources at bootup time and 
stick with them.

in the -rt tree we also have clockevents and HRT support, so the clocks 
used should depend on whether you have the APIC enabled in the .config, 
and whether the BIOS has it enabled by default. If the BIOS has the APIC 
disabled then you can force the kernel to enable it by adding "lapic" to 
the boot-line.

without the APIC active, the equation is simple: we use the PIT for both 
jiffies and HRT. We use the TSC for gettimeofday. No interaction between 
the two.

if the APIC is active, then we have both the local APIC timer interrupt 
for and the PIT for HRT timing. The clockevents framework sees both 
hardware clocks and automatically decides which one to use, based on 
their ranking. A typical PIT reprogramming PIO sequence takes 20-30 
usecs, while a typical APIC timer reprogramming takes ~5 nanoseconds on 
my box, so the choice is rather easy ;-) The jiffies interrupt is still 
off the PIT. gettimeofday is off the TSC counter.

i could imagine the following hardware effects to cause time warps:

- the TSC is in fact the 'read counter' method of the local APIC timer 
  hardware. So there can be interactions in theory: programming the APIC 
  timer could impact the TSC and vice versa. There have been CPU 
  erratums in this area in the past.

- powersaving can impact the TSC - and can thus impact the APIC timer 
  too. Errata-land as well.

- the TSC itself could have short, temporary warps. I had a box that
  showed such effects.

besides hardware bugs, another, albeit very small possibility is that 
somewhere in the thousands of lines of shiny-new generic-time-of-day, 
ktimers, clockevents and high-res-timers code, there is a software bug, 
which is causing time warps ;-)

	Ingo