From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: [PATCH] clocksource=tsc Date: Fri, 18 Jul 2008 16:00:57 +0100 Message-ID: References: <20080718085606203.00000001344@djm-pc> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080718085606203.00000001344@djm-pc> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "dan.magenheimer@oracle.com" , "Xen-Devel (E-mail)" Cc: Dave Winchell List-Id: xen-devel@lists.xenproject.org On 18/7/08 15:56, "Dan Magenheimer" wrote: > 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. I don't think this is necessarily true. If we write code to generate accurate time records specifically for clocksource=tsc then we should easily get accuracy down to a couple of parts per billion. This is certainly a more pragmatic solution than extending the guest time interfaces. I am at least coming round to the fact that the changes required in Xen's time.c are going to have to be a bit more drastic than I first hoped. -- Keir