RE: [Xen-devel] [PATCH] TSC scaling for live migration between platforms with different TSC frequecies

["Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>]

Dan Magenheimer wrote:
>>> On HVM or VMWare we don't even try, since we can't possibly know the
>>> real CPUs skew: the assumption is the VM platform has already done
>>> this for us. And at least Xen attempts to sync up the physical CPUs.
>>> Significant drift (where different CPUs are ticking at different
>>> rates) is bad news, and can easily lead to non-monotonicity. I don't
>>> know what "significant" means though, unfortunately.
>> 
>> We can guanrantee each vcpu's TSC is increasing
>> monotonically, but there maybe some diff between vcpus.  I am
>> not sure 10^5 cycles is significant, but it should exceed a
>> stable hardware's drift in general.
> 
> Let me attempt to define "significant":
> 
> Assume that two kernel- or user-threads are able to synchronize
> such that they can guarantee execution order.  If:
> 
> 1) thread A reads TSC, and then
> 2) thread A and thread B sync to guarantee ordering, and then
> 3) thread B reads TSC, but
> 4) thread B's TSC value is less than thread A's TSC value
> 
> then the TSC skew is "significant".
> 
> If thread A and thread B are for example using TSC values
> to timestamp journal transactions, then transaction guarantees
> will not be valid.

Agree.

> So the question becomes: What is the smallest number of
> cycles that are required to allow thread A and thread B
> to synchronize for ordering?

This is the key point to determin whether we can perform furture optimization.  
If the skew between vcpus can't be ignored, we should have no fast way to 
handle it and have to resort to TSC emulationand suffer the performance loss. 
But anyway, TSC emualtion method should be the first step to go. 

> I assert that this value is low enough _in theory_ that
> only full TSC emulation can guarantee the proper result.
> In _practice_, I don't know.  But I suspect that
> it is much lower than 10^5 cycles.

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