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] Re: [PATCH] clocksource=tsc

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH] clocksource=tsc
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 18 Jul 2008 08:56:06 -0600
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Delivery-date: Fri, 18 Jul 2008 07:57:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4A6676B.244C5%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/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: AcjkZ5sqwfzsRK8bRLOogZ+uDOy+agBK8Gg8AAvqplAALhkLxQADB+XQAAFG8VoAATgKoAAAlQPwABMp4zAABk1eMAARsq0wAAB8cZgAR4se4AARsDekAAeSCxIAAEo1uwAGMYeAAADIYbQAAK6J0A==
> > So perhaps the compromise which I've (admittedly accidentally)
> > crafted is the right answer for now.  And the right answer for
> > later is to update the PV time mechanisms (in a backwards
> > compatible way of course) to determine if an ideal timesource
> > is available and use it if it is.
> 
> Well, maybe, although I don't see we have any guarantee that 'platform
> system time' and Xen's get_s_time won't diverge in absolute 
> terms as time
> passes. The scale factors each use are calculated somewhat 
> independently.
> Actually I think it may get it right just now, but it looks 
> rather fragile
> and it stores up trouble for systems with long uptimes if you 
> get it wrong.
> There's no particular reason not to generate fresh time 
> records every few
> seconds and use those both in Xen and in guests, using the existing
> compute-system-time algorithm.

It appears that, for clocksource=tsc, as long as both
read_platform_stime() and get_s_time() are returning
scaled-tsc there can be no divergence.

The issue with generating fresh time records every
few seconds is that it unnecessarily introduces jitter
into an otherwise ideal timesource.

Dan



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