qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [kvm-devel] [PATCH 1/3] Refactor AIO interface to allow


From: Daniel P. Berrange
Subject: [Qemu-devel] Re: [kvm-devel] [PATCH 1/3] Refactor AIO interface to allow other AIO implementations
Date: Thu, 17 Apr 2008 21:00:24 +0100
User-agent: Mutt/1.4.1i

On Thu, Apr 17, 2008 at 02:41:32PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Thu, Apr 17, 2008 at 02:26:50PM -0500, Anthony Liguori wrote:
> >  
> >>Posix AIO, especially as used by QEMU, is not very efficient for disk IO.
> >>This patch introduces an AIO abstract to allow multiple AIO implements to 
> >>be
> >>used.  We can't simply replace posix-aio by linux-aio because linux-aio 
> >>only
> >>works on some filesystems and only with files opened with O_DIRECT.
> >>
> >>This patch adds a command line option (-aio) to select the AIO 
> >>implementation
> >>to be used.  It avoids code motion to allow for easy review.  The next 
> >>patch
> >>separates out the posix-aio implementation.
> >>    
> >
> >This is not a very pleasant user experiance. They can not & should not be
> >expected to figure out which AIO impl works with their particular 
> >filesystem.
> >If the linux-aio impl doesn't work in some cases, then the code should 
> >detect
> >these and automatically fallback to posix-aio. The user should not have to
> >use a -aio flag to make it work.
> >  
> 
> Those cases aren't always discoverable.  Linux-aio just falls back to 
> using synchronous IO.  It's pretty terrible.  We need a new AIO 
> interface for Linux (and yes, we're working on this).  Once we have 
> something better, we'll change that to be the default and things will 
> Just Work for most users.

If QEMU can't discover cases where it won't work, what criteria should
the end user use to decide between the impls, or for that matter, what
criteria should a management api/app like libvirt use ? If the only decision
logic is  'try it & benchmark your VM' then its not a particularly useful
option.

I've basically got a choice of making libvirt always ad '-aio linux'
or never add it at all. My inclination is to the latter since it is
compatible with existing QEMU which has no -aio option. Presumably
'-aio linux' is intended to provide some performance benefit so it'd
be nice to use it. If we can't express some criteria under which it
should be turned on, I can't enable it; where as if you can express
some criteria, then QEMU should apply them automatically.

Pushing this choice of AIO impls to the app or user invoking QEMU just
does not seem like a win here.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

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