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: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, 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: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 28 May 2010 06:47:32 +0100
Delivery-date: Thu, 27 May 2010 22:48:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <789F9655DD1B8F43B48D77C5D30659731E78D89D@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acr9rpJYA+BrOykCR6yHgEJ6dUO4GgAZaAKgAAVEYmo=
Thread-topic: [Xen-devel] [RFC] Physical hot-add cpus and TSC
User-agent: Microsoft-Entourage/
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.
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.

 -- Keir

Xen-devel mailing list

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