[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


 


Rackspace

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