This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "John Levon" <levon@xxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [PATCH] rendezvous-based local time calibration WOW!
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 6 Aug 2008 07:25:50 -0600
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 06 Aug 2008 06:27:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080805211251.GA27007@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acj3x+/yzZYv7edhT/eIRJtVI9B8dQ==
> > 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.

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

<Prev in Thread] Current Thread [Next in Thread>