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

2008-04-17 Thread Anthony Liguori
Daniel P. Berrange wrote:
> 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.
>   

The one thing we could possibly do is detect the cache where we see a 
block device and then automagically enable cache=off and -aio linux.  
Without cache=off, -aio linux is not so useful ATM.  At the same time 
though, not all users are going to want to disable the use of the host 
page cache.  It's not necessary an easy decision either way.

For libvirt, I'd recommend just never using -aio linux.  We'll have a 
better AIO option in the near future (based on Rusty's vringfd work) and 
I'd like to detect and enable that by default.

Regards,

Anthony Liguori

> Dan.
>   


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


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

2008-04-17 Thread Daniel P. Berrange
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 :|

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


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

2008-04-17 Thread Anthony Liguori
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.

Regards,

Anthony Liguori

> Dan.
>   


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


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

2008-04-17 Thread Daniel P. Berrange
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.

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 :|

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel