On Sat, Jul 29 2006, Paul Brook wrote: > > Easy to do with the fsync infrastructure, but probably not worth > > doing since people are working on the AIO I/O backend, which would > > allow multiple outstanding writes from a guest. That, in turn, > > means I/O completion in the guest can be done when the data really > > hits disk, but without a performance impact. > > Not entirely true. That only works if you allow multiple guest IO > requests in parallel, ie. some form of tagged command queueing. This > requires either improving the SCSI emulation, or implementing SATA > emulation. AFAIK parallel IDE doesn't support command queueing.
Parallel IDE does support queuing, but it never gained wide spread support and the standard is quite broken as well (which is probably _why_ it never got much adoption). It was also quite suboptimal from a CPU efficiency POV. Besides, async completion in itself is not enough, QEMU still needs to honor ordered writes (barriers) and cache flushes. > My impression what that the initial AIO implementation is just > straight serial async operation. IO wouldn't actually go any faster, > it just means the guest can do something else while it's waiting. Depends on the app, if the io workload is parallel then you should see a nice speedup as well (as QEMU is then no longer the serializing bottle neck). -- Jens Axboe _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
