[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [RFC] Physical hot-add cpus and TSC
> From: Dong, Eddie [mailto:eddie.dong@xxxxxxxxx] > > > Below is test result: > > a) With the patch > > Before hotadd: > > (XEN) TSC marked as reliable, warp = 0 (count=3) > > (XEN) No domains have emulated TSC > > (XEN) TSC marked as reliable, warp = 0 (count=4) > > (XEN) No domains have emulated TSC > > (XEN) TSC marked as reliable, warp = 0 (count=5) > > (XEN) No domains have emulated TSC > > (XEN) TSC marked as reliable, warp = 0 (count=6) > > (XEN) No domains have emulated TSC > > > > After add > > (XEN) TSC marked as reliable, warp = 1669912421214 (count=15) > > (XEN) No domains have emulated TSC > > (XEN) TSC marked as reliable, warp = 1669912421214 (count=16) > > (XEN) No domains have emulated TSC > > If the warp is fixed, at least for HVM, this can be solved by adjusting > the TSC_OFFSET with the additional warp to make guest see warp=0 for > TSC invariant case. Anything missed? Hi Eddie -- Two things: 1) The TSC_OFFSET doesn't work for PV domains. 2) For HVM, it is very difficult to choose a precise TSC_OFFSET so that it passes a warp test. If it doesn't pass a warp test, upstream kernels will stop using tsc as a clocksource resulting in a big performance loss... and some applications that use TSC and are not TSC resilient that may have been working fine for weeks may suddenly break due to an event (adding a physical CPU to Xen) that neither the app nor its (guest) OS is able to detect. Dan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |