[Top][All Lists]

[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: Anthony Liguori
Subject: [Qemu-devel] Re: [kvm-devel] [PATCH 1/3] Refactor AIO interface to allow other AIO implementations
Date: Thu, 17 Apr 2008 15:05:52 -0500
User-agent: Thunderbird (X11/20080227)

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

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.


Anthony Liguori


reply via email to

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