RE: Xen system skew MUCH worse than tsc skew (was RE: [Xen-devel]RE: [PATCH] record max stime skew (was RE: [PATCH] strictly increasinghvm guest time))

["Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>]

> Is it too expensive to do once/second?  If it's not more expensive
> than the (1Hz per processor) local_time_calibration(), perhaps we
> should just use it to set TSC on all processors once/second and
> dispense
> with the existing (beautiful but one additional frequency to resonate)
> platform-timer-interpolated-by-tsc approach?

It doesn't need to be done very frequently, e.g. every 10-30s -- anytime
before the TSC wraps should work.

> On the other hand, I'll bet the bigger the system, the more difficult
> it is to rendezvous them... 

Yes, but it shouldn't be too horrendous -- we have to do stuff like this
for some (rare) synchronous TLB flushes anyhow. 

> and the more natural skew there will be between the sockets.

This skew will still be tiny, sub microsecond.

> > The only thing that could mess this up would be NMI's or SMI's. You
> > could at least detect that by reading the TSC after all CPUs have
> > incremented the counter, and check that only a "reasonable" amount
of
> > time had elapsed. If not, set a flag to indicate that a
> > recalibration is
> > required (you'd need to add another gather loop to enable all CPUs
to
> > vote on whether they're happy).
> 
> I think I've seen this code in recent Linux.

It's worth implementing this just to see how good a job we could do.

Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel