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] System time monotonicity

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [xen-devel] System time monotonicity
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 9 Apr 2008 12:36:33 -0600
Delivery-date: Wed, 09 Apr 2008 11:37:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C422B022.1EF7F%keir.fraser@xxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/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
> >> This is all true. The logic in vpt.c should be fixed to use
> >> Xen's concept of
> >> system time and everything, guest TSC included, should be
> >> derived from that.
> >
> > Does Xen's concept of system time have sufficient resolution
> > and continuity to ensure both monotonicity and a reasonable
> > guest timer granularity?  I'm thinking not; some form of
> > interpolation will probably be necessary which will require
> > reading a physical platform timer** (e.g. other than tsc).
> Xen's system time provides nanosecond precision and is 
> intended to be as
> accurate as the underlying platform timer (over long periods) and as
> granular and accurate as the TSC over sub-second periods. 
> It's quite good enough for any guest purposes.

OK, as long as the maximum uncorrected drift between physical TSCs
does not exceed the guest-expected granularity of its virtual
platform timer, I agree its good enough.

It appears that TSC drift for each pcpu is corrected by Xen
once per second.  Any idea for real systems out there what the
maximum drift (per second) is?  Will this be affected by
existing or future power-savings designs (e.g. is it possible
for the TSCs in one socket to be slowed down while the TSCs
in another socket are not)?  If so, as Kevin points out,
some kind of affinity enforcement might be necessary for
time-sensitive VMs.

Xen-devel mailing list