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

["Wei, Gang" <gang.wei@xxxxxxxxx>]

On Friday, December 12, 2008 5:32 PM, Keir Fraser wrote:
> 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.

Yes, I will do it this way.

> 
> 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?

My tsc_skew testing method is:
1. specify "cpuidle hpetbroadcast cpufreq=xen" in grub xen line.
2. start 4 UP rhel5u1 hvm guest
3. 'xm vcpu-pin ...' to pin all vcpus of dom0 & all guests to cpu1(total 2 
pcpus in my box)
4. run 'while true; do find . /; done' in several guests
5. trigger keyhandler of 't' from time to time to watch the time skew & cycle 
skew.

I observed the cycle skew easily exceeded ten seconds in hours.

> 
>> 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?

In my box, the existing initial tsc->ns scale:
    .mul_frac=ca1761ff, .shift=-1 (2533507879 ticks/sec)
and the stable calibrated  tsc->ns scale in nopm case:
    .mul_frac=ca191f43, .shift=-1(2533422531 ticks/sec)
Don't you think the inaccuracy is a little big (85348 ticks/sec)? But It is not 
really easy to improve it. I will keep using the existing scale for this 
moment. We can keep looking whether we can find a better way to improve it.

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