Re: xen PIT timer

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

Keir,

Thanks for the explanation.  I'm still trying to reason out why we are
seeing the 'Time went backwards' every now and then, as well as being able
to forcibly create the issue via serial interrupt floods (holding 'r'
with serial input sent to Xen).

Is either assumption, PIT_CH0 ~= 10ms (Linux) or PIT_CH2 = 1.119380Mhz
source (Xen) more valid?  It sounds like either is valid.  Though Linux
can be adjusted via ntpd, is there any correcting factor for Xen?  I
know we can run ntpd in dom0 and it can update the wall clock timer, but
AFAICT, wall clock doesn't affect system_timestamp (which is where we
detect the Time went backwards in 
linux-2.6-xen-sparse/arch/x86/xen/i386/kernel/time.c).

Via some trace observation, I've noticed that the per-cpu time in Xen
(specifically stime_local_stamp) can vary widely between cpus.  Is this
the best source to be using for updating Linux system_timestamp since it
can vary significantly ( >1000000 ) between processors?

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?

Do you have any other suggestions on where I should investigate?  I know
this isn't a problem for most folks, but we are still concerned that it
shows up every now and then on our platform under Xen, though we don't
see any of the Linux lost_tick stuff when running Linux.

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