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

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> > 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.

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?

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.

Dan