RE: [Xen-devel] [RFC] Physical hot-add cpus and TSC

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>-----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 
right?

--jyh

>
> -- Keir
>


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