Re: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 12/12/2008 03:36, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:

> I am updating the original patch for constant_tsc case. There are some
> questions.
> 
> The first question is, can we just replace the per-second tsc_scale
> calibration with constant tsc_scale & per-second tsc restoring? For
> constant_tsc, it seems meaningless to do the tsc_scale calibration works. And
> to make the tsc_skew as small as possible, it is better to do the tsc resync
> per-second other than once a minute or even less.

If you mean have the same tsc_scale in all per_cpu(cpu_time).tsc_scale, then
yes. And you can do your once-a-second work in time_calibration() -- you can
put an if-else in there.

I thought our tsc_skew was looking quite good now with the updated
scale_reciprocal(), by the way. How much more drift is there for you to
wring out?

> The second question is, how can we make a more accruate tsc_scale and use it
> for all local NOW() calculation & tsc restoring? Current initial tsc->ns scale
> is based on PIT, but it is not certain to be the platform timer source. Is it
> practical to make tsc_scale calibration working for seconds and take the
> calibrated tsc_scale as the globle and fixed one?

You don't want a platform source, right? So what does it matter? The more
important question is: how much inaccuracy is built in to the existing
tsc->ns scale factor compared with real wallclock progress of time? And how
easily can that be improved? The fact that PIT may wander relative to HPET,
for example.... Who cares?

 -- Keir



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