Hi! > >>In general, I/O in a virtual guest is subject to > >>performance problems. The I/O can not be completed > >>physically, but must be virtualized. This > >>means trapping and decoding port I/O instructions from > >>the guest OS. Not only is the trap for a #GP > >>heavyweight, both in the processor and > >>the hypervisor (which usually has a complex #GP path), > >>but this forces > >>the hypervisor to decode the individual instruction > >>which has faulted. Worse, even with hardware assist > >>such as VT, the exit reason alone is > >>not sufficient to determine the true nature of the > >>faulting instruction, > >>requiring a complex and costly instruction decode and > >>simulation. > >> > >>This patch provides hypercalls for the i386 port I/O > >>instructions, which > >>vastly helps guests which use native-style drivers. > >>For certain VMI > >>workloads, this provides a performance boost of up to > >>30%. We expect > >>KVM and lguest to be able to achieve similar gains on > >>I/O intensive > >>workloads. > >> > >> > > > >What about cost on hardware? > > > > On modern hardware, port I/O is about the most expensive > thing you can do. The extra function call cost is > totally masked by the stall. We have measured with port > I/O converted like this on real hardware, and have seen > zero measurable impact on macro-benchmarks. > Micro-benchmarks that generate massively repeated port > I/O might show some effect on ancient hardware, but I > can't even imagine a workload which does such a thing, > other than a polling port I/O loop perhaps - which would > not be performance critical in any case I can reasonably > imagine. SCSI controller in ISA slot? IDE without DMA enabled? Yes, those are performance-critical. The second case seems common with compactflash cards. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
