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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel