[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH v8 for-xen-4.5] Fix interrupt latency of HVM PCI passthrough devices.
Changelog: since v7 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg04385.html) - Put ref-counting back, added two bits to allow ref-counting from other places. since v6 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg03208.html) - Squashed #1 + #2. - Added more comments, redid it based on Jan's feedback. since v5 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg02868.html) - Redid the series based on Jan's feedback since v4 (http://lists.xen.org/archives/html/xen-devel/2014-09/msg01676.html): - Ditch the domain centric mechansim. - Fix issues raised by Jan. The patches are an performance bug-fixes for PCI passthrough for machines with many sockets. On those machines we have observed awful latency issues with interrupts and with high steal time on idle guests. The root cause was that the tasklet lock which was shared across all sockets. Each interrupt that was to be delivered to a guest took the tasket lock - and with many guests and many PCI passthrough devices - the performance and latency were atrocious. These two patches fix the outstanding issues. I am in a weird position to be the release-manager and also submitting patches past the feature freeze. This is a fix (a performance one) but at the same time the work that it does is adding new code which could be considered a feature. It does not have an Ack from anybody, albeit Jan and Andrew have heavily been reviewing the patchset. I don't think we have any specific policy for this - so I am going to go on the safe side and try to justify it as if it is an feature. - It definitly adds to the awesome++ part of the Xen 4.5 by lowering the latency of interrupts _and_ removing steal time from guests. - From the risk perspective - it does not deal with the common use-cases, but only with the 'PCI passthrough one'. As such, it replaces some of that core code which means it brings a risk to it. I've done my best to eliminate this by doing various tests - passing in buggy hardware, legacy hardware, MSI and MSI-X hardware. All of them work the same way as they did before. But of course there is still a risk. - If this code is not added in Xen 4.5 the release will still be awesome, but not awesome++ :-) xen/Makefile | 2 +- xen/arch/arm/domain.c | 12 -- xen/arch/x86/domain.c | 23 +-- xen/arch/x86/hvm/hvm.c | 4 +- xen/arch/x86/hvm/viridian.c | 60 ++----- xen/arch/x86/hvm/vlapic.c | 27 +--- xen/arch/x86/setup.c | 2 +- xen/common/domain.c | 26 ++- xen/drivers/passthrough/io.c | 284 +++++++++++++++++++++++++++++---- xen/drivers/passthrough/pci.c | 29 +++- xen/include/asm-x86/hvm/hvm.h | 9 +- xen/include/asm-x86/hvm/viridian.h | 27 ---- xen/include/asm-x86/softirq.h | 3 +- xen/include/public/arch-x86/hvm/save.h | 1 - xen/include/xen/domain.h | 4 - xen/include/xen/hvm/irq.h | 5 +- xen/include/xen/pci.h | 2 +- 17 files changed, 316 insertions(+), 204 deletions(-) Konrad Rzeszutek Wilk (2): dpci: Move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model. dpci: Replace tasklet with an softirq (v8) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |