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 system skew MUCH worse than tsc skew (was RE: [Xen-devel] RE: [P

To: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: Xen system skew MUCH worse than tsc skew (was RE: [Xen-devel] RE: [PATCH] record max stime skew (was RE: [PATCH] strictly increasing hvm guest time))
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 11 Jul 2008 22:27:52 +0100
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Delivery-date: Fri, 11 Jul 2008 14:28:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080711145339796.00000003744@djm-pc>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjcXTkqnSPaEESHRsmD1HhwJkyawAAAIPEpAAuAJ0AAAgl0IAAT2dqMABFKNxAAAHEqUAAGNaGwAAdfXjQAIb9HAAAAjWJ4AAico9AAAPZ0lAECdtJAABGXRyYAHMJkcAAXKn0wABhjCqAAAt2KdQ==
Thread-topic: Xen system skew MUCH worse than tsc skew (was RE: [Xen-devel] RE: [PATCH] record max stime skew (was RE: [PATCH] strictly increasing hvm guest time))
User-agent: Microsoft-Entourage/11.4.0.080122
On 11/7/08 21:53, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> 1) by a boot option, or
> 2) by the TSC_CONSTANT cpu flag, or
> 3) when determined dynamically to be safe using code similar
>    to arch/x86/tsc_sync.c in recent Linux kernels
> 
> (1) is by far the easiest (perhaps not too late for 3.3?)
> while (3) is clearly the best for users but adds lots of
> code (bloat/untested)

(1) is perhaps fine.

How does (2) work? The individual CPUs do not know whether they are
synchronised across the mainboard. I think constant-tsc is necessary
(individual CPUs must not vary their multiplier of the input clock rate) but
may not be sufficient.

I don't know how much code is involved in (3).

 -- Keir



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

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