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
