Re: xen PIT timer

[Ryan Harper <ryanh@us.ibm.com>]

* Keir Fraser <Keir.Fraser@cl.cam.ac.uk> [2005-09-26 10:45]:
> >I haven't gotten around to doing it yet, but I was going to instrument
> >irq disable/enable to see how long we run with irq's disable with the
> >thought that we might be missing some events from which Xen derives 
> >time
> >calculations.  Is this a worthwhile investigation?
> 
> It would be interesting. Unless you are sync'ed to the PIT you should 
> be able to go reasonably long periods with no timer interrupts with no 
> ill effects (except the CPU time may get to wander off track a little 
> more than it would otherwise have done). If you are sync'ed to the PIT 
> (you have no cyclone, hpet or other chipset timer) then CPU0 needs to 
> take a timer interrupt at least every 50ms or it will miss the 16-bit 
> PIT counter wrapping.

Interesting.  So, in the case of the dual-opteron box, we are slaved to
the PIT, and while there is an HPET (or at least Xen was happy when I
booted with hpet_force=1), it is not detectable via ACPI code
(i.e. ACPI tables don't include an ACPI_HPET table).

In the case where I can force the timer to miss via serial interrupts, I
believe we are preventing CPU0 from taking a timer interrupt within
50ms. 

The other case where I see 'Time went backwards' is during dom0 boot up.
I'll dig into tracking the frequency of timer interrupts.

Speaking of timer interrupts, why doesn't the xen timer_interrupt()
actually handle the platform timer read and overflow check there rather
than raising a softirq?

Thanks a lot for the help Keir.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@us.ibm.com