[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Guest TSC and Xen (Intel and AMD feedback please)
>From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx] >Sent: 2008年7月3日 9:21 >> >> Can't be the tsc kept monotonic to guest, with some tweak on >> tsc offset? Also Xen is always trying to sync tsc among cores. >> As long as you don't run on a box with multiple bus crystals, >> or a box without constant tsc upon freq change, the tsc drift >> among cores should be negligible considering the overhead of >> migration. Then for cases out of 'as long as', we should mark >> TSC as unstable, still as an option. > >No Xen doesn't actally sync the tsc's, just maintains its own >software offset variables. I suppose it could periodically check >to make sure the tsc skew is within some reasonable value, >but after the guest boots, it is probably too late. You are right. Xen only sync TSCs at boot time and then calibrate TSC pace independently on each cpu. If some factors drag TSC in the middle, then we may observe larger drift. But now I'm not sure whether periodically sync among cpus is light enough, if taking a similar convergence algothrim as boot time. But still, if only TSC drift exists (caused by occasional events instead of a constantly increasing drift from freq difference), this monotonic can be easily exposed to the guest, like derived from xen system time to adjust TSC offset at migration... > >> >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? >> >> Agree. > >Is this something that you (or Intel in general) could look at? >I would be happy to participate but I don't think I understand >VT well enough. Once the trap occurs, I suppose Xen system time >could be used as the virtual TSC, possibly scaled up. > There should be tiny related to VT, as only turning on some bit to allow RDTSC trapping and then the rest stuff should be common how to handle it. We'll take a look, but can't commit the time due to other scheduled bandwidth. But if you'd like to jump in early we definitely can help with VT side. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |