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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (xen-devel@xxxxxxxxxxxxxxxxxxx)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Physical hot-add cpus and TSC
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Fri, 28 May 2010 14:29:21 +0800
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Thu, 27 May 2010 23:30:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8251784.161BE%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: <789F9655DD1B8F43B48D77C5D30659731E78D89D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C8251784.161BE%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acr9rpJYA+BrOykCR6yHgEJ6dUO4GgAZaAKgAAVEYmoAAJQ2UA==
Thread-topic: [Xen-devel] [RFC] Physical hot-add cpus and TSC

>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: Friday, May 28, 2010 1:48 PM
>To: Jiang, Yunhong; Dan Magenheimer; Xen-Devel (xen-devel@xxxxxxxxxxxxxxxxxxx);
>Ian Pratt
>Subject: Re: [Xen-devel] [RFC] Physical hot-add cpus and TSC
>On 28/05/2010 06:39, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>>> Hmmm... I'd be very surprised if this works ever, let alone
>>> always across all hardware.  By "work", I mean that it will
>>> result in an "undetectably small difference" (less than a
>>> cache bounce), as defined and measured by the tsc warp test.
>>> Why?  Because rdtsc is a long instruction (30-100 cycles)
>>> and I'll bet writing to the TSC is even longer.  Plus,
>>> there's a cache bounce overhead added in due to the
>>> synchronization via the in-memory tsc_count variable.
>> I think that depends how we define " undetectably". If the time that guest
>> migration among physical CPU is much higher than this difference, do we 
>> really
>> need care about it (of course SMI/NMI is another story)?
>> Or I missed anything?
>"Undetectable" by Dan's definition means undetectable by a multi-threaded
>app on a multi-vcpu guest. Any detected warp would therefore be a problem.

Thanks for explain. I didn't realize this requirement.

>It is impossible to meet that level of TSC consistency when doing CPU
>physical-add, without emulating all guest TSCs. We may need to add that as
>an option, at least, to keep a small class of apps that care (like Oracle's
>DB, we assume) happy.

So a option to make TSC_MODE_DEFAULT as d->arch.vtsc=0 ?.
When CPU_hotadd, we should at least warning if that option is not set, am I 


> -- Keir

Xen-devel mailing list

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