Re: [Qemu-devel] Re: [PATCH][RFC] Refactor AIO to allow multiple AIO implementations

[Anthony Liguori]

Jamie Lokier wrote:
> I'm under the impression that linux-aio is better in every way, as
> I think Anthony Liguori posted a while back:
>
>   
> > > >  Threads are a poor substitute for a proper AIO interface.
> > > >  linux-aio gives you everything you could possibly want in an
> > > >  interface since it allows you to submit multiple vectored operations
> > > >  in a single syscall, use an fd to signal request completion,
> > > >  complete multiple requests in a single syscall, and inject barriers
> > > >  via fdsync.
> > > >         

Well that Anthony Liguori guy is obviously smoking crack.

The problem with linux-aio is that it doesn't work unless you open a 
file with O_DIRECT.  There is no simple way to make it work with 
buffered files either because of the silliness of the vfs interface.

I know buffered vs. unbuffered IO is a source of contention for some but 
if you're doing largely homogeneous virtualization, and you happen to 
have common storage (either via a common backing file or something more 
sophisticated), buffered IO is going to make a big difference.

There are at least three thread pool implementations in the kernel to 
allow asynchronous IO to buffered files.  If the kernel is doing this 
internally, userspace has no hope of being able to do it differently.

BTW, my current thinking for a thread pool implementation would actually 
use linux-aio in each thread, but using it to emulate preadv/pwritev.

Regards,

Anthony Liguori


> But knowing about request in flight, I/O ordering etc. seem equally
> available via posix-aio on a distro where that calls linux-aio
> (i.e. not the Glibc implementation).
>
> -- Jamie
>