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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, 'Keir Fraser' <keir.fraser@xxxxxxxxxxxxx>, "Wei, Gang" <gang.wei@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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 16 Dec 2008 08:58:35 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Mon, 15 Dec 2008 16:59:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0A882F4D99BBF6449D58E61AAFD7EDD603BB493F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <8FED46E8A9CA574792FC7AACAC38FE7701C7C99F09@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C56C2FFC.203C4%keir.fraser@xxxxxxxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD603BB493E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD603BB493F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclWoeM2xc+X6mj6QOaQHsyxDmpzagAFRoNpAAEP6tAAAWmCgAAATdDsAAIJ5qAAAvL7GQFMKVOwAA1xISwAJTEgYAANxIuJAAtYh4AAAOh3kwBJ7/4QAAz5nPAABgajLwACXuJwAAX6iocAES/KAAAA65pQAAB/wdA=
Thread-topic: [Xen-devel] Re: [PATCH] CPUIDLE: revise tsc-save/restore to avoid big tsc skew between cpus
Again, another wrong comment was given by me since the
sequence is correct. Not sure my bad mind in such a good
morning. :-( Jimmy is now trying your suggestion to sync
TSC MSR in time calibration softirq.

Thanks,
Kevin

>From: Tian, Kevin 
>Sent: Tuesday, December 16, 2008 8:45 AM
>To: Tian, Kevin; 'Keir Fraser'; Wei, Gang; 
>
>Forgot below comment and I read your patch too quickly.
>
>It's supposed to work, and maybe some sequence issue reverts
>the effect you want to achieve. For example, at least the lines
>within init_xen_time is useless, since calibrate_tsc_ap happens
>later which will update AP tsc_scale. Anyway, this looks in a
>right direction, and we'll do some debug to find the exact reason.
>
>Thanks,
>Kevin
>
>>From: Tian, Kevin
>>Sent: Tuesday, December 16, 2008 8:29 AM
>>
>>>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>>>Sent: Tuesday, December 16, 2008 12:02 AM
>>>
>>>On 15/12/2008 13:28, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:
>>>
>>>>>> Redo the constant_tsc & tsc_nostop check part and post it again.
>>>>> 
>>>>> I applied the bits outside time.c. For time.c itself, how 
>>>about the simpler
>>>>> attached alternative? Does it work well? :-)
>>>> 
>>>> Although it looks simpler & workable, but the practice shows 
>>>it doesn't work.
>>>
>>>Weird. I wonder if CPU TSCs aren't as synced as we'd like, and 
>>>we're getting
>>>a -ve TSC delta in get_s_time(). Perhaps setting the TSC MSR to
>>>r->master_tsc_stamp in time_calibration_rendezvous() would 
>avoid that.
>>>
>>
>>I'm not sure why you don't want to adjust TSC. Whether cpu TSCs
>>are sync-ed or not doesn't make sence if TSC will stop when
>>individual core enters deep C-state. As long as multiple cpus get
>>difference chance in deep C-state, finally you always has increasing
>>TSC skews. Whatever you can do in Xen side w/o adjusting TSC,
>>it only helps those aware of xen system time, e.g. pv guest. However
>>for hvm guest, TSC skew always causes problem.
>>
>>I think no software approach can cleanly solve this TSC skew, unless
>>with hardware assistance like always running tsc. Since Jimmy's
>>approach can work far better than previous one, (yes, we know some
>>weakness when one cpu doesn't enter deep C-state for a long time),
>>it's still worthy of slipping in? In the meantime, IMO your change can
>>be also required, since there's no much need for periodic time calib-
>>ration upon a constant tsc feature. But it's a seperate issue as we
>>aim to solve. :-)
>>
>>Thanks,
>>Kevin
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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