Re: [Qemu-devel] [patch] non-blocking disk IO

[Jens Axboe <qemu@kernel.dk>]

On Mon, Oct 03 2005, John Coiner wrote:
> 
> 
> Jens Axboe wrote:
>  > Why not use aio for this instead, seems like a better fit than spawning
> >a thread per block device? That would still require a thread for
> >handling completions, but you could easily just use a single completion
> >thread for all devices for this as it would not need to do any real
> >work.
> 
> Pthreads vs. AIO is an open question.
> 
> The pthreads implementation works with all disk image formats, without 
> modifying any format-specific code. To use AIO, each image format driver 
> would have to be modified.

That is true, I appreciate why you did it the way you did. Using libaio
would be more invasive, indeed.

> QEMU already uses pthreads, therefore using pthreads does not add a new 
> dependency on the host platform. (Or so I thought. The build on Windows 
> broke anyway. Haha... my bad...)
> 
> My questions are:
>  * Which QEMU host platforms support Posix AIO?
>  * Which host platform has the slowest pthreads library, and how many 
> cycles will it waste on pthreads overhead?
>  * What is the likely performance benefit of using AIO?
> 
> When I have time, I'll hack AIO into the "raw" image driver, and take 
> some benchmarks on a linux host.

Using aio would result in cleaner design in the end, but it would
require extra host specific code for the abstraction. It's also
non-buffered, which may or may not be a win for qemu (it should be,
would be trivial to test this with the existing code already).

For the normal case of a single or two block devices, performance of the
threaded vs libaio model will likely be the same. For many block
devices, libaio would definitely be a big improvement.

At least on Linux, the posix aio model is not worth spending time on, as
it just relies on threading as well on the glibc side. Then you might as
well just keep the design you have now.

BTW, thanks for starting this work, it's sorely needed! A future
experiment would be to write a sata/scsi qemu driver so you could do
sane command queueing. Since file layout isn't always perfect, that
should further increase the io performance.

-- 
Jens Axboe