[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains
On 23/01/18 17:45, George Dunlap wrote: > On 01/22/2018 06:39 PM, Andrew Cooper wrote: >> Juergen: you're now adding a LTR into the context switch path which >> tends to be very slow. I.e. As currently presented, this series >> necessarily has a higher runtime overhead than Jan's XPTI. > > So here are a repeat of the "hypervisor compile" tests I did, comparing > the different XPTI-like series so far. > > # Experimental setup: > Host: > - Intel(R) Xeon(R) CPU E5630 @ 2.53GHz > - 4 pcpus > - Memory: 4GiB > Guest: > - 4vcpus, 512MiB, blkback to raw file > - CentOS 6 userspace > - Linux 4.14 kernel with PV / PVH / PVHVM / KVM guest support (along > with expected drivers) built-in > Test: > - cd xen-4.10.0 > - make -C xen clean > - time make -j 4 xen > ... > * Staging + Juergen's v2 series > real 1m3.018s > user 2m52.217s > sys 0m40.357s > > Result: 63s (0% overhead) > > Unfortunately, I can't really verify that Juergen's patches are having > any effect; there's no printk indicating whether it's enabling the > mitigation or not. I have verified that the changeset reported in `xl > dmesg` corresponds to the branch I have with the patches applied. > > So it's *possible* something has gotten mixed up, and the mitigation > isn't being applied; but if it *is* applied, the performance is > significantly better than the "band-aid" XPTI. As there is no real mitigation in place, but only the needed rework of the interrupt handling and context switching, anything not next to xpti=off would have been disappointing for me. :-) I'll add some statistics in the next patches so it can be verified the patches are really doing something. Thanks for doing the tests, Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |