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 14:48:37 -0600
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ben Guthro <bguthro@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 09 Jun 2008 13:51:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C4729C01.199E9%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: AcjIFBNOSTfhtJHySxCkafUaaZcKSgBjZoBVAAHlHtAABTaSTAARWR2JABqYZAA=
> 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.

That said, if Dave's patch achieves the stated accuracy on most
versions of Linux (e.g. at least RHEL4+5, 32+64, smp+1p) for SOME
set of parameters (which might be different on each Linux version),
it would still be better than what we have now.

The ideal solution, I think, would be for the default hvm settings
to "do the right thing" for both Windows and Linux at least for the
vast majority of configuration choices.  I'm not sure this is possible,
but it sure would be nice.

Dan

-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Monday, June 09, 2008 1:36 AM
To: Dave Winchell; dan.magenheimer@xxxxxxxxxx
Cc: Ben Guthro; xen-devel
Subject: Re: [Xen-devel] [PATCH 0/2] Improve hpet accuracy


On 9/6/08 00:26, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> wrote:


> 4) config file parameters

Hpet enabled. Timer_mode set to HVM_HPET_guest_computes_missed_ticks
for all Linux guests and to HVM_HPET_guest_does_not_compute_missed_ticks
for Windows 2k8-64 and Vista 64.
8 vcpus for Linux and 2 for Windows.


These new HVM_HPET options seems a weird design choice. It appears that you can 
only set these or one of the old options, so there's not actually any 
independence between the mode used by vpt.c and the mode used by hpet.c. 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.

I'd be more agreeable to a partch that stripped out the physical hpet accesses 
(since you say they are not the reason for the improvement in accuracy), built 
hpet on top of vpt, and added the necessary extra mechanisms to deal with 
interrupt broadcasts into vpt.c. And which was split into more separate pieces 
of mechanism.

 -- Keir


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