Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool

[Andrea Arcangeli <aarcange@redhat.com>]

My current feeling is that this user thread aio thing will never
satisfy enterprise usage and kernel aio is mandatory in my view. I had
the same feeling before too, but I thought clone aio was desiderable
as intermediate step, because it could help whatever other unix host
OS that may not have native aio support. But if there's a problem with
opening the file multiple times (which btw is limiting the total
number of bdev to a dozen on a default ulimit -n with 64 max threads,
but it's probably ok), then we could as well stick to glibc aio, and
perhaps wait it to evolve with aio_readv/writev (probably backed by a
preadv/pwritev). And we should concentrate on kernel aio and get rid
of threads when host OS is linux. We can add a dependency where the
dma api will not bounce and linearize the buffer, only if the host
backend supports native aio.

Has anybody a patch implementing kernel aio that I can plug into the
dma zerocopy api? I'm not so sure clone aio is worth maintaining
inside qemu instead of evolving glibc and kernel with preadv/pwritev
for the long term.

Thanks!