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>
Subject: RE: [xen-devel] System time monotonicity
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 11 Apr 2008 16:05:32 -0600
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Delivery-date: Fri, 11 Apr 2008 15:07:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C424C854.1632F%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/DABz2x8AAFJ7thgAfm1ow
> If we wanted to be more certain we could maintain a 
> last_system_time fields per VCPU and

If you mean per VCPU *and* per guest this seems like
a good idea.

> backwards, by turning small backwards deltas into very short 
> periods of stalled time.

The stalled time may be a problem, but only if the tsc skew
between processors is "bad".  Your estimate of 100us seems
like it could be unacceptable for some applications.

Any idea how expensive arch/x86/time.c:local_time_calibration()
is?  If it's not too bad, one option might be to add a xen
boot parameter "calibratehz" to calibrate more frequently.
Then systems running time-sensitive guests can be instructed
to increase the parameter accordingly to ensure tsc skew
is small enough.

> > 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.
> 
> If we wanted to be more certain we could maintain a 
> last_system_time fields
> per VCPU and, whenever using system time to compute current 
> value for a
> virtual timer for an HVM VCPU, we could actually use max(system time,
> last_system_time). This would mean we were 100% sure that 
> time didn't go
> backwards, by turning small backwards deltas into very short 
> periods of
> stalled time.
> 
> As it is: no, since system time 'free runs' on each CPU over 
> one-second
> periods, there can be drift between CPUs if they are driven 
> by different
> oscillators. Also there are tolerances in our software 
> calibration code to
> consider. Which is why Linux guests implement the max(curr 
> time, last time)
> in their gettimeofday() code. It would be quite reasonable to 
> the same,
> inside Xen, for HVM guests. We can at least be pretty certain that any
> drifts across CPUs/VCPUs will be on the order of less than 100us.
> 
>  -- Keir
> 
> 
>


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