Re: [PATCH] Add I/O hypercalls for i386 paravirt

[Pavel Machek]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/