From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: Re: [PATCH] clocksource=tsc Date: Fri, 18 Jul 2008 08:56:06 -0600 Message-ID: <20080718085606203.00000001344@djm-pc> References: Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , "Xen-Devel (E-mail)" Cc: Dave Winchell List-Id: xen-devel@lists.xenproject.org > > 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=3Dtsc, 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