On Fri, Jun 19, 2009 at 10:25:36AM +0800, Zhang, Xiantao wrote:
> Actually, we had done some optimizations and make most of rdtsc not
> trap to hypervisor and always keep tsc monotonically increasing in
> each virtual processor, but it is hard to solve the tsc drift issue
> between all vcpus. In our solution, tsc drift may exceeds 100000
> cycles. You know, TSC drift maybe also exist in real platforms, but
> maybe not quite large like 1000000 cycles. Do you know what's the
I'm not sure what you mean by "drift of 1000000 cycles". In what time
period? Or are you talking about skew (a constant difference between TSC
values read between CPUs) ? Solaris handles arbitrary skew (I think) but
that's only accounted for at boot time. A fudge factor (tsc_max_delta)
accounts for any minor post-calibration deltas.
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.
Finally, a change across all CPUs in the tsc tick rate (so no drift, but
a sudden change after, say, a migration) is also bad news. Solaris used
to recalibrate the scale rate once a second, but that was removed.
All this is HVM/metal code of course.
regards
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home