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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

I observed with the attached patch (on a machine
with invariant TSC) that cstate_restore_tsc()
has very poor precision; the value that is written
to TSC on C3 recovery seems like it should be
within a handful of cycles of being accurate
(which on a invariant TSC can be precisely
compared).  Instead, it was off by 200,000
cycles or more!  This was counter-intuitive
so I dug through the code a bit to see if
there is an obvious bug.

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!

Tsc_scale -- and cpu_khz which is tsc_scale/1000 --
are used in other places as well; one of interest to
me is in hvm_gtsc_need_scale()... for TSC to work
properly across certain migrations, this test needs
to be very precise.   There may be others.

Anyway, I wonder if there is a more precise
way of determining the exact TSC Hz rate,
particularly on machines with constant/invariant TSC?

I found one such method in Examples 9-5 and 9-6 in:

http://www.intel.com/Assets/PDF/appnote/241618.pdf

Or maybe there's a better way using ACPI tables
or cpufreq?  And hopefully there's a method that
can work for both AMD and Intel processors?  If
nothing else, we should probably pick up the
latest Linux native_calibrate_tsc() code which has
grown considerably more complicated.

Thanks,
Dan

P.S. Note that to reproduce my test, the
hpetbroadcast Xen boot parameter must be set,
else no C3 events occur.

P.P.S. Yes, I realize that the write_tsc() on all
processors in time_calibration_tsc_rendezvous()
is intended to fix any synchronization lost by
an imprecise setting in cstate_restore_tsc().
I was testing to see if the rendezvous'd write
was really necessary (and perhaps counter-
productive!) when I discovered this imprecision
problem.

tsc_scale_prob.patch
Description: Binary data

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