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 10:51:35 -0600
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Delivery-date: Fri, 18 Jul 2008 09:52:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4A66EB9.244DA%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+XQAAFG8VoAATgKoAAAlQPwABMp4zAABk1eMAARsq0wAAB8cZgAR4se4AARsDekAAeSCxIAAEo1uwAGMYeAAADIYbQAAK6J0AAAaB4RAAJwCWA=
> 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

I guess you are correct as long as "generate a time record"
doesn't include recomputing the scaling factor every
second (which is I think what introduces the jitter... see
more on this below).

However, I'm not sure why you perceive the aesthetics to
be so bad to put "if (ideal_clocksource)" in get_s_time()
and a few other places in time.c... or for that matter in
the PV guest code.

Your existing algorithm is a very cool and elegant way to
optimize time handling for all "legacy" time sources.
The more I understand about it, the more I am impressed!
But it is very difficult to understand and for most "modern"
hardware it unnecessarily obfuscates time handling.  So IMHO
I much prefer the "if (ideal_clocksource)... else ..."
approach rather than shoehorning the ideal to look like
the legacy.  And that applies for the PV guest code as well.

On a related note:

> The problem is that this is sensitive to small errors in the 
> scale factor!
> And unfortunately we compute a new scale factor, to convert to us, as
> scale_factor_ns/1000. The resulting scale factor is obviously 
> less accurate,
> and leads to an accumulating absolute error as the TSC value 
> gets large.

Yes I noticed that the mul_frac+scale_delta code gives different
answers than muldiv64, though they have essentially the same API.
I didn't do much testing but they differed after about 5 digits
and muldiv64 does a hardware divide so I suspect it is more
accurate (though also probably slower).  It might be worth looking
at this to squeeze out more precision.

Thanks for all your time and attention on this.  As Xen supports
more time-sensitive workloads (such as databases on enterprise
systems and games on PCs), I think it will pay off!

Dan


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