From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: [PATCH 0/2] Improve hpet accuracy Date: Thu, 12 Jun 2008 16:51:16 -0600 Message-ID: <20080612165116781.00000057128@djm-pc> References: <20080610194420109.00000041832@djm-pc> Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20080610194420109.00000041832@djm-pc> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "dan.magenheimer@oracle.com" , Dave Winchell , Keir Fraser Cc: xen-devel , Ben Guthro List-Id: xen-devel@lists.xenproject.org > > In EL5u1-32 however it looks like the fractions are accounted > > for. Indeed the EL5u1-32 "lost tick handling" code resembles > > the Linux/ia64 code which is what I've always assumed was > > the "missed tick" model. In this case, I think no policy > > is necessary and the measured skew should be identical to > > any physical hpet skew. I'll have to test this hypothesis though. > = > I've tested this hypothesis and it seems to hold true. > This means the existing (unpatched) hpet code works fine > on EL5-32bit (vcpus=3D1) when hpet is the clocksource, > even when the machine is overcommitted. A second hypothesis > still needs to be tested that Dave's patch will not make this worse. OK, I can confirm that Dave's patch, as expected, does not make this any worse. The timer algorithm in 2.6.18 for x86 (i.e. RHEL5-32bit) is definitely the most resilient to variations in tick delivery for a monotonically-increasing timesource (i.e. hpet). This algorithm is in arch-independent code but sadly x86_64 didn't use it as of 2.6.18. Dan