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: Fri, 12 Dec 2008 11:36:44 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Thu, 11 Dec 2008 19:37:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C55ED0BB.9BC%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: <0A882F4D99BBF6449D58E61AAFD7EDD601E23C36@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C55ED0BB.9BC%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclWoeM2xc+X6mj6QOaQHsyxDmpzagAFRoNpAAEP6tAAAWmCgAAATdDsAAIJ5qAAAvL7GQFMKVOw
Thread-topic: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus
On Friday, December 05, 2008 8:36 PM, Keir Fraser wrote:
> It does depend on constant_tsc though. That's fine, but I think then it
> should be implemented as an alternative method selected only when you detect
> constant_tsc at runtime. The fallback should be something like Gang Wei
> posted most recently.
> 
> Also don't use cpu_khz as it's way less accurate than you need to put up
> with. Create a 'struct time_scale' that will convert from nanoseconds to TSC
> ticks. I think a reciprocal function for time_scale's would be useful here
> (and in Gang Wei's last patch as well) as then you can take the existing
> initial TSC->ns scale and flip it.
> 
> The other concern I have is that, even with a much more accurate scale
> factor, CPUs which do not enter deep-C (because they are running busy loops
> for example) will *slowly* wander from the time line determined by your
> scale factor (due to unavoidable imprecision in the scale factor). This
> could build up to be noticeable over days. It might be an idea therefore to
> occasionally force a TSC resync on any CPU that hasn't had it resynced for
> other reasons, just to zap any accumulating imprecision that has crept in.
> It'd only need to be done maybe once a minute or maybe even much less than
> that.

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.

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?

Jimmy

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

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