From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: [PATCH 0/2] Improve hpet accuracy Date: Mon, 9 Jun 2008 15:46:26 -0600 Message-ID: <20080609154626562.00000002776@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 , Dave Winchell Cc: xen-devel , Ben Guthro List-Id: xen-devel@lists.xenproject.org > >> 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