From: "Dan Magenheimer" <dan.magenheimer@oracle.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>,
Dave Winchell <dwinchell@virtualiron.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
Ben Guthro <bguthro@virtualiron.com>
Subject: RE: [PATCH 0/2] Improve hpet accuracy
Date: Mon, 9 Jun 2008 14:48:37 -0600 [thread overview]
Message-ID: <20080609144837187.00000002776@djm-pc> (raw)
In-Reply-To: <C4729C01.199E9%keir.fraser@eu.citrix.com>
> 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@eu.citrix.com]
Sent: Monday, June 09, 2008 1:36 AM
To: Dave Winchell; dan.magenheimer@oracle.com
Cc: Ben Guthro; xen-devel
Subject: Re: [Xen-devel] [PATCH 0/2] Improve hpet accuracy
On 9/6/08 00:26, "Dave Winchell" <dwinchell@virtualiron.com> 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
next prev parent reply other threads:[~2008-06-09 20:48 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-05 14:59 [PATCH 0/2] Improve hpet accuracy Ben Guthro
2008-06-06 8:58 ` Keir Fraser
2008-06-06 10:45 ` Dave Winchell
2008-06-06 15:53 ` Dan Magenheimer
2008-06-06 17:54 ` Dave Winchell
2008-06-06 19:33 ` Dave Winchell
2008-06-06 20:29 ` Dan Magenheimer
2008-06-06 22:34 ` Keir Fraser
2008-06-07 21:20 ` Dave Winchell
2008-06-09 21:07 ` Dan Magenheimer
2008-06-09 21:44 ` Dave Winchell
2008-06-08 20:32 ` Dave Winchell
2008-06-08 21:10 ` Dan Magenheimer
2008-06-08 23:26 ` Dave Winchell
2008-06-09 7:36 ` Keir Fraser
2008-06-09 11:13 ` Dave Winchell
2008-06-09 12:03 ` Keir Fraser
2008-06-09 12:10 ` Keir Fraser
2008-06-09 13:08 ` Dave Winchell
2008-06-09 20:48 ` Dan Magenheimer [this message]
2008-06-09 21:18 ` Keir Fraser
2008-06-09 21:46 ` Dan Magenheimer
2008-06-08 21:18 ` Dan Magenheimer
2008-06-09 22:02 ` Dan Magenheimer
2008-06-09 23:34 ` Dave Winchell
2008-06-10 3:21 ` Dan Magenheimer
2008-06-11 1:44 ` Dan Magenheimer
2008-06-11 13:58 ` Dave Winchell
2008-06-11 16:47 ` Dan Magenheimer
2008-06-12 22:51 ` Dan Magenheimer
2008-06-10 7:52 ` Keir Fraser
2008-06-10 11:49 ` Dave Winchell
2008-06-10 12:34 ` Dave Winchell
2008-06-10 12:42 ` Keir Fraser
2008-06-10 17:13 ` Dave Winchell
2008-06-11 8:30 ` Keir Fraser
2008-06-11 11:38 ` Dave Winchell
2008-06-06 15:35 ` Steven Hand
2008-06-06 17:34 ` Dave Winchell
[not found] <4851940F.2050307@virtualiron.com>
2008-06-12 22:05 ` Dan Magenheimer
2008-06-12 22:49 ` Dave Winchell
2008-06-13 4:47 ` Dan Magenheimer
2008-06-13 7:33 ` Keir Fraser
2008-06-13 15:39 ` Dan Magenheimer
2008-06-13 12:08 ` Dave Winchell
2008-06-13 14:58 ` Dave Winchell
2008-06-13 15:52 ` Dan Magenheimer
2008-06-13 16:53 ` Dave Winchell
2008-06-13 0:38 ` Dave Winchell
2008-06-13 2:21 ` Dan Magenheimer
2008-06-13 3:12 ` Dave Winchell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080609144837187.00000002776@djm-pc \
--to=dan.magenheimer@oracle.com \
--cc=bguthro@virtualiron.com \
--cc=dwinchell@virtualiron.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.