[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] heavy P2M lock contention on guest HPET counter reads
On 30/07/14 11:08, Jan Beulich wrote: > Hi, > > with 40+ vCPU Win2012R2 guests we're observing apparent guest live > locks. The 'd' debug key reveals more than half of the vCPU-s doing an > inlined HPET main counter read from KeQueryPerformanceCounter(), > resulting in all of them racing for the lock at the beginning of > __get_gfn_type_access(). Assuming it is really necessary to always > take the write lock (rather than just the read one) here, would it perhaps > be reasonable to introduce a bypass in hvm_hap_nested_page_fault() > for the HPET page similar to the LAPIC one? > > Thanks, Jan We have received similar concerns about the emulation overhead of the vhpet, but not with a guest that size. One complication is that the HPET can optionally be emulated by qemu based on an HVMPARAM, so the fastpath has to consider creating an ioreq. (Frankly, I think this ability is completely mad, and I doubt anyone would notice if it ceased to work. There is no reason to use qemu's emulation in preference to Xen's, especially as Xen's emulatator was copied from qemu at some point in the past) Have you enabled with viridian extensions? Providing the TSC enlightenments should cause Windows to completely ignore the vhpet. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |