RE: [PATCH 0/2] Improve hpet accuracy

["Dan Magenheimer" <dan.magenheimer@oracle.com>]

> > 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=1) 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