WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid bi

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus
From: "Wei, Gang" <gang.wei@xxxxxxxxx>
Date: Sat, 13 Dec 2008 12:01:30 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Fri, 12 Dec 2008 20:02:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C567E009.20272%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <8FED46E8A9CA574792FC7AACAC38FE7701C78F40B6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C567E009.20272%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclWoeM2xc+X6mj6QOaQHsyxDmpzagAFRoNpAAEP6tAAAWmCgAAATdDsAAIJ5qAAAvL7GQFMKVOwAA1xISwAJTEgYA==
Thread-topic: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus
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

<Prev in Thread] Current Thread [Next in Thread>