WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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: Thu, 10 Apr 2008 15:27:28 -0600
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Delivery-date: Thu, 10 Apr 2008 14:29:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C4237B92.1627B%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
Thread-index: AciZl4WQxEBTGAWKEd2fxQAWy6hiGQABBvOAABCRjTAAAOXDcAAXM6WgAANRGxAAARCZ3gACXwsQAAHJ8dYAA5cIYAAauX/DABz2x8A=
> > 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.
> 
> Ignoring power-saving events, TSCs are crystal-driven and hence we can
> expect specified tolerance of a few ppm across temperature 
> extremes, and in
> practice over few-second periods I would expect tolerance of 
> better than
> 1ppm. *However* I have seen platform timers (which also should be
> crystal-driven) which inexplicably exhibit much worse behaviour.

OK... back to monotonicity for a moment:

So regardless of ppms and thermal and P-state and drifts,
are you confident that the current corrected-tsc mechanism
will never see time going backwards for the following test?
(Apologies for pseudo-code, but hope you get the drift...
pun intended).

global val1, proceed = 0;

Guest thread 1:
spin_lock(lock);
val1 = read_hpet();
proceed = 1;
spin_unlock(lock);

Guest thread 2:
while (!proceed);
spin_unlock_wait(lock);
val2 = read_hpet();
if (val2 < val1) PANIC();

If you are not confident that this will be OK on existing and
(within-reason) future Xen platforms, perhaps the hvm virtual
platform timers should (at least optionally) be built on physical
platform timers (Dave Winchell cc'ed), which would ensure time
never goes backwards.

> > 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.
> 
> P-state changes are informed to Xen so we can re-sync the local TSC
> immediately. The tricky ones are unannounced thermal events 
> because software
> does not get informed about those. On some systems we can 
> turn them off, on
> others (new Intel platforms) TSC is constant-rate regardless. 
> In a normal
> running system thermal events are rare.

If it is possible to write code that can determine at
boot-time (or at hotplug cpu_online) what CPUs are
guaranteed-sync'ed with what other CPUs, it would be
nice if this information was exported by Xen
so that tools can manage very-time-sensitive guests
appropriately.

Personally, I think this code should be provided by the
CPU vendors ;-)

Dan


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