RE: [Xen-devel] Re: tsc_scale/cpu_khz imprecise and need fixing?

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> > I *think* the reason is that tsc_scale, which
> > I believe is set only once per processor at startup
> > on machines with constant/invariant TSC, is set
> > imprecisely using init_pit_and_calibrate_tsc().
> > I suspect the imprecision is compounded through
> > the reciprocal operation.  AND I wonder if an ill-timed
> > power management event might render tsc_scale not
> > just imprecise, but just plain wrong!
> 
> The 50ms calibration period may not be long enough, we could 
> put the PIT in
> square-wave mode instead and count 10 50ms periods...

To support this, it appears that the value returned
by init_pit_and_calibrate_tsc(), which is essentially
"cpu_hz", varies by about 20K or more from boot to boot
on the same hardware.

> However this may not improve matters since the PIT may tick at quite a
> different rate than the stated frequency. A crystal can 
> easily be 100ppm off
> from what's stamped on the can. Really we should calibrate 
> the TSC to the
> platform timer that we choose to use

I suppose this is probably true for the crystal driving
TSC as well.  Which lowers any expectation of "matching"
cpu_khz across a migration (in Xiantao's HVM approach). 

> Perhaps we should update tsc_scale
> even for invariant tsc, just to fold in extra precision after 
> boot. E.g.,
> tsc_scale = alpha*old_tsc_scale +
> (1-alpha)*(new_sys_time-old_sys_time)/(new_tsc-old_tsc)
> and increase alpha towards 1 over time, as we develop trust 
> in the value of
> tsc_scale. Where new/old tsc and system-time values would be across a
> calibration rendezvous period.

Interesting.  How do you "develop trust"?  And is this
guaranteed to converge?  If it "flutters", it might make
matters worse.

You may want to look at the new Linux code as it tries
to choose the best result from a number of methods,
and even tries to weed out SMI's:

http://lxr.linux.no/linux+v2.6.31/arch/x86/kernel/tsc.c#L399

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