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/
Home Products Support Community News


RE: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Sun, 5 Apr 2009 21:37:30 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "john.v.morris@xxxxxx" <john.v.morris@xxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Sun, 05 Apr 2009 06:38:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5FE7064.6E87%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: <0A882F4D99BBF6449D58E61AAFD7EDD61024D381@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C5FE7064.6E87%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acm0q3HSSZiKszrATIOXS9rDQ0InwgBGJPUmAAiiyiAAAu+2dwAAE0jg
Thread-topic: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: 2009年4月5日 21:28
>On 05/04/2009 13:17, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>> One concern I have however, is Intel's
>>> X86_FEATURE_CONSTANT_TSC logic. This
>>> was added by them to prevent TSCs from diverging due to Cx 
>deep sleep
>>> states, by observing that usually all TSCs will tick at the
>>> same exact rate,
>> Here one correction is, that constant tsc logic is introduced for
>> P-states instead of C-states, to have TSC always stepping in
>> constant pace on a given processor, regardless of whatever
>> opertion point is being requested by cpufreq governor. It
>> doesn't say anything that all TSCs tick at same rate however.
>Then changeset 18923 is indeed broken and should be reverted? 
>The problem is
>this changeset doesn't just affect the cases it is meant to 
>'fix' (usage of
>C states for CPUs without no-stop TSC). Apart from the fact it 
>can be broken
>for systems with that type of CPU as well, it's actually 
>enabled for any
>modern CPU (anything advertising the constant-tsc feature). Probably I
>shouldn't have checked in that patch in the first place.

How about making it a selectable option, instead of reversing
it completely?

Xen-devel mailing list