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: Tue, 5 Aug 2008 14:49:25 -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: Tue, 05 Aug 2008 13:54:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080805185651.GB9615@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: Acj3PLrgAYMVmyYTSIicEt3lfGL0CA==
The algorithm used to compute the timestamp information
that's passed up to a PV domain has been re-worked to
result in a much lower inter-CPU skew.  The old
algorithm had a worst case of 10us to 40 us (depending
on how it was measured).  The new algorithm appears
to have a worst case which is sub-microsecond, though
it needs more exposure and hasn't been tested on a wide
variety of boxes.  To measure it on your box, in domain0,
run the following (or equivalent) for a few hours:

watch "xm debug-key t; xm dmesg | tail -2"

However, it's still not perfect and so is not guaranteed
to be monotonic across two CPUs, though it might be good
enough to be effectively monotonic in many environments.
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".

I've thought about implementing softtsc for PV domains for
this reason.  (Softtsc was just added at 4.0 for hvm domains
and causes all hvm tsc reads to trap.)  Would this be of

> -----Original Message-----
> From: John Levon [mailto:levon@xxxxxxxxxxxxxxxxx]
> Sent: Tuesday, August 05, 2008 12:57 PM
> To: Dan Magenheimer
> Cc: Keir Fraser; Xen-Devel (E-mail); Ian Pratt; Dave Winchell
> Subject: Re: [Xen-devel] RE: [PATCH] rendezvous-based local time
> calibration WOW!
> On Mon, Aug 04, 2008 at 01:40:06PM -0600, Dan Magenheimer wrote:
> > * Greatly improved precision for time-sensitive SMP VMs
> I wonder if we could get a more detailed summary of all the 
> changes that
> have been made here?
> Will this let us stop taking a global lock in our PV time routine to
> ensure monotonicity?
> regards
> john

Xen-devel mailing list

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