[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Guest TSC and Xen (Intel and AMD feedback please)
Various versions of Linux under various circumstances select TSC as the primary clocksource for the kernel. This is especially true for uniprocessor kernels, but also in some cases for multiprocessor kernels. In most cases, this is because a processor bit (tsc_invariant? constant_tsc?) is passed through directly from the hardware via Xen and tested by the hvm guest and the result implies that the TSC is "stable". I'd like to propose that, for a Xen hvm guest, TSC should NEVER be considered stable. For at least these reasons: 1) Often this test is done once at guest boot; if the guest migrates to another machine without the bit set, time will be erratic. 2) I *think* that in some cases even within the same system, TSC values will skew somewhat. Since a uniprocessor guest will often be rescheduled to a different pcpu by Xen, the underlying tsc may appear erratic. Comments (especially from Intel and AMD)? If agreed, could Intel and AMD provide patches so that hvm reads of the bits return "false"? Or will this cause other problems? Another alternative would be to trap all rdtsc's and emulate them but this probably will not be easy and may have significant performance implications. But perhaps it should be an option? Dan =================================== Thanks... for the memory I really could use more / My throughput's on the floor The balloon is flat / My swap disk's fat / I've OOM's in store Overcommitted so much (with apologies to the late great Bob Hope) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |