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] [PATCH 0/2] Improve hpet accuracy

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/2] Improve hpet accuracy
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 9 Jun 2008 15:46:26 -0600
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ben Guthro <bguthro@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 09 Jun 2008 14:48:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C4735CB9.19A1F%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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/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: AcjIFBNOSTfhtJHySxCkafUaaZcKSgBjZoBVAAHlHtAABTaSTAARWR2JABqYZAAAAh8/sAAAit3Q
> >> At guest install time you ought to be able to tell whether 
> the guest
> >> will use hpet or not based on its version (RHELx, SLESy, 
> Winz etc etc)
> >> and decide whether missed-ticks accounting is required or not.
> >
> > Unfortunately this is not true on Linux, at least without gathering
> > (and hardcoding) more information about the system.  Whether hpet is
> > used or not is dependent not only on the OS/version and hvm config
> > parameters, but also on kernel command line parameters and even
> > the underlying CPU.  For example, on RHEL5u1, if the tsc is 
> synchronized
> > and the CPU is Intel, and no kernel parameters are chosen, 
> tsc will be
> > chosen as the default clocksource even if hpet is present.  Ugly.
> 
> It's not immediately obvious that adding further independent 
> configuration
> knobs to twiddle would make our lives that much easier. 
> However it certainly
> increases the test matrix.

I fully agree.  That's why I think the default parameters in Xen
should "do the right thing".  The default will get the most
testing and if users say "time hurts when I change the parameters"
we can say "then don't change the parameters" ;-)

> In your example above, by synchronised TSC do you mean 
> constant-rate TSC?
> That can at least be hidden in CPUID now.

I meant synchronized as defined in 2.6.18/arch/x86_64/kernel/time.c
in the function unsynchronized_tsc() and as used in the same file
in time_init_gtod().  To make this more complicated, these routines
have had not-insignificant bug fixes in RHEL5u1/2.

But yes, it might be a good idea if X86_FEATURE_CONSTANT_TSC
always returns 0 (or at least is configurable and defaults off),
since the test may only be made in the guest at boot time and
the guest may migrate to a machine without the feature.

More ugliness, I know.  My head hurts.

Dan


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