| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] xen PIT timer
* Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> [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@xxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home