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] [RFC] Physical hot-add cpus and TSC

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Physical hot-add cpus and TSC
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Wed, 2 Jun 2010 17:17:17 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Xen-Devel \(xen-devel@xxxxxxxxxxxxxxxxxxx\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 02 Jun 2010 02:19:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C053E35.8040804@xxxxxxxx>
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: <789F9655DD1B8F43B48D77C5D30659731E78D370@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C823EF64.1603B%keir.fraser@xxxxxxxxxxxxx> <789F9655DD1B8F43B48D77C5D30659731E78D500@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <3c99c55d-68ce-4150-b895-72fda1ff3b89@default> <789F9655DD1B8F43B48D77C5D30659731E78D89D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <26342d1d-2141-4fb1-94ac-a398d7f553d6@default> <789F9655DD1B8F43B48D77C5D30659731E78DA70@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <2d0b4e25-6fa9-4d66-9efe-a1b9e27612f5@default 789F9655DD1B8F43B48D77C5D30659731E7EC349@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87987703-973e-4d24-ba9f-091a97ed3384@default> <4C053E35.8040804@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcsBrOgzE4Gxt/92Q0ah7M39s8tLAgAeY42w
Thread-topic: [Xen-devel] [RFC] Physical hot-add cpus and TSC

>-----Original Message-----
>From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
>Sent: Wednesday, June 02, 2010 1:07 AM
>To: Dan Magenheimer
>Cc: Jiang, Yunhong; Keir Fraser; Xen-Devel (xen-devel@xxxxxxxxxxxxxxxxxxx); Ian
>Pratt
>Subject: Re: [Xen-devel] [RFC] Physical hot-add cpus and TSC
>
>On 05/31/2010 05:30 PM, Dan Magenheimer wrote:
>>> BTW, I notice one more thing, when system booting w/o hotplug, the warp
>>> is 0. However, after I return back after weekend, I noticed the warp is
>>> 182. Because I did the hotplug action before getting the warp, I'm not
>>> sure if it's caused by the hotplug action, or the system TSC will drift
>>> very slowly.
>>>  (XEN) TSC marked as reliable, warp = 182 (count=2)
>>>
>> Hmmm... I'm much more worried about this case and would
>> like to understand this better.  If this is reproducible
>> on real-world QPI systems, and there is no way to a priori
>> determine that "this is a system where even though the
>> Invariant TSC bit is set, this system may drift", then
>> there is no way Invariant TSC can be exposed to a guest.
>>
>
>Some crappy BIOSes will attempt to hide the time taken by a SMI by
>save/restoring tsc over the call.  Could something like that be
>happening here?
>
>One of the nicest upcoming tsc-related architectural changes is that the
>cpus will expose both the underlying base tsc counter, and the offset
>used to compute rdtsc; a wrtsc will just end up adjusting that offset
>without affecting the underlying counter, making it easy to tell when
>people are trying to play games with the tsc (and also making the
>process of adjusting the tsc one of determining the offset, independent
>of trying to place games with updating a racing tsc).
>

Because that data is collected after a weekend, so I'm not sure if anything 
happen to the system (for example, someone may hot-add a CPU but I'm unware of 
it and didnt check it). I will retry it this weekend. At least after running 
for half day this morning, I didn't find such issue again.

Per my understanding, the TSC should be stable, a lot of effort has been made 
so that TSC is reliable in the system.

--jyh

>> /me can hear Jeremy biting his tongue hard to avoid
>> saying "I told you so". ;-)
>>
>
>...
>
>    J

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

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