Re: [Xen-devel] RE: [PATCH] rendezvous-based local time calibration WOW!

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Wed, Aug 06, 2008 at 07:25:50AM -0600, Dan Magenheimer wrote:

> > > I'm not sure its possible to guarantee monotonicity in
> > > PV domains (without a global lock) except by doing a trap
> > > or hypercall at each "get time".
> > 
> > That's a shame.
> 
> Further followup on this...
> 
> I'd encourage you to put some test code in your lock to
> see if time ever measurably goes backwards.  It may never,
> or it may only on some ill-behaved-tsc machines or when
> cpufreq changes occur... needs testing.  Even if it
> does, it may be by a smaller delta than all but the
> most sophisticated SMP applications can detect.

I believe the normal (metal) Solaris algorithm expects any inter-CPU TSC
differences to remain static (that is, no drift), so any machine that
breaks that is problematic:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86pc/os/timestamp.c

(Compare:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86xpv/os/xpv_timestamp.c
)

The presumption is that gethrtimef() is monotonically increasing, which
at least Xen 3.0.4 regularly broke. If the hypervisor has been fixed to
give as much guarantees as we got already then great.

A monotonic gethrtime() is part of the ABI so I'm not sure we can avoid
a lock even on well-behaved machines if Xen isn't correct.

I wonder if we couldn't do something when we know that we're scheduling
a VPCU onto a different CPU to ensure time can't go backwards.

Anyway, some more testing sounds like it would be interesting.

regards
john

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