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

[Anthony Liguori <aliguori@us.ibm.com>]

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