[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.