Re: [Xen-devel] Re: VT is comically slow

["Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>]

> The QEMU code that we use doesn't go through the dom0 buffer cache, we modified 
> the
> code to use O_DIRECT.  Can't user buffer cache and accelerated drivers (they go 
> right
> to the disk) together, it can cause disk corruption.  The performance numbers 
> we get
> from this version of QEMU is still 4 to 6 times slower that native disk I/O.
I doubt O_DIRECT buys you much in the way of performance -- as you say
it's just a correctness thing.  Still, the qemu block code is all
completely synchronous -- the fact that you simply can't have more
than a single outstanding block request at a time is going to
seriously harm performance.  As Anthony explained, some form of
asynchronous IO in the qemu drivers would clearly improve performance.

> You might be right, however even with pipelining and async I/O, I don't think 
> it is going to get close to native I/O numbers.  I guess we'll just have to wait
> and see.
I'd expect that disk can be made to perform reasonably well with qemu,
using dma emulation and async IO.  The old vmware workstation paper on
device virtualization does a pretty good job of demonstrating that
trap and emulate device access sucks, and would seem to imply that
it's pretty unlikely to be practical for high-rate networking.

a.

[1] http://www.usenix.org/event/usenix01/sugerman/sugerman.pdf

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel