qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 1/2] pci-dma-api-v1


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC 1/2] pci-dma-api-v1
Date: Sun, 30 Nov 2008 16:38:19 -0600
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Andrea Arcangeli wrote:
On Fri, Nov 28, 2008 at 07:59:13PM +0200, Blue Swirl wrote:
I don't know, here's a pointer:
http://lists.gnu.org/archive/html/qemu-devel/2008-08/msg00092.html

I'm in total agreement with it. The missing "proper vectored AIO
operations" are bdrv_aio_readv/writev ;).

I wonder how can possibly aio_readv/writev be missing in posix aio?

Because it sucks.

Unbelievable. It'd be totally trivial to add those to glibc, much
easier infact than to pthread_create by hand, but how can we add a
dependency on a certain glibc version?

I've already asked, Ulrich will not likely add this unless it first goes into the Posix standard. It won't go into the Posix standard without an existing implementation. Either way, we're talking about a multi-year process.

We need our own thread-pool based AIO implementation.

 Ironically it'll be more
user-friendly to add dependency on linux kernel-aio implementation
that is already available for ages and it's guaranteed to run faster
(or at least not slower).

No, kernel-aio is more brain dead. io_submit may block if the underlying file descriptor does not support asynchronous IO. There is no way to detect this. This means the only safe way to use io_submit is to call it from a thread, and to have a thread pool that can do multiple io_submits in parallel.

Yes, that's ridiculous. There's a thread right now on address@hidden discussing the future of linux-aio. The prevailing wisdom seems to be that linux-aio does not have a future.

Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]