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

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

> > 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.
Why?...

On my (admittedly well-behaved-tsc) machine, I've now
run a quarter-million samples on the new code.  The
"xm debug-key t" code now prints out both stime skew
and tsc. The results (TSC scaled for easier reading):

stime: max 349ns avg 114ns
TSC:   max 342ns avg  89ns

This is a dual-core Conroe so the TSC is supposedly
synchronized; so the differences are probably more due
to inter-CPU cache synchronization in the measurement code
than actual skew.

My currently running test code also records distribution
for stime skew. 99% of the samples are less than 200ns,
0.9% are 200ns-300ns, and 0.01% are greater than 300ns
(and less than the max of 349ns).   This compares to the
previous algorithm in which I measured ~2% greater than
1us and a few greater than 10us.  The old code was also
sensitive to load, with average skew increasing when
domains were busy.  The new code should be insensitive
to load.

So still no guarantees, but I do think this qualifies
as "greatly improved" and may also meet your needs.


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