[libvirt] [PATCH v2] qemu: Add option to enable/disable IOEventFD feature

[Eric Blake]

On 05/19/2011 04:09 PM, Stefan Hajnoczi wrote:
>>  In case we need to refine later, we can still provide a larger set of
>> accepted values for that attribute, assuming people really want to
>> make more distinctive tuning,
> 
> Inventing a different name makes life harder for everyone.  There is a
> need for a generic API/notation that covers all virtualization
> software but this is a hypervisor-specific performance tunable that
> does not benefit from abstraction.

That's true if we narrow-mindedly think that qemu will be the _only_
hypervisor that will ever use this feature.  But libvirt has the stated
goal of accommodating multiple hypervisors, so we'd rather go with the
generic name even if it requires more mapping.

> When I ask a user to try disabling ioeventfd I need to first search
> through libvirt documentation and/or source code to reverse-engineer
> this artificial mapping.  This creates an extra source of errors for
> people who are trying to configure or troubleshoot their systems.  The
> "I know what the hypervisor-specific setting is but have no idea how
> to express it in libvirt domain XML" problem is really common and
> creates a gap between the hypervisor and libvirt communities.

Yes, good documentation that mentions the specific qemu option it maps
to would be helpful.

Also, libvirt has the domxml-from-native command, and if we do this
correctly, then you should be able to pass an arbitrary qemu command
line to libvirt, and ask what the corresponding xml would be.  That
would make your reverse mapping less difficult.

> 
> The next time an optimization is added to QEMU you'll have to pick a
> new name, "asyncio" (already overloaded terminology today) won't be
> available anymore.  We're going to end up with increasingly contrived
> or off-base naming.

Then please help us, by suggesting a generic name more suited to this
particular qemu tuning, but which can still be used for other
hypervisors if they can also tune the same semantics.

> 
> Regarding semantics:
> 
> Ioeventfd decouples vcpu execution from I/O emulation, allowing the VM
> to execute guest code while a separate thread handles I/O.  This
> results in reduced steal time and lowers spinlock contention inside
> the guest.  Typically guests that are experiencing high system cpu
> utilization during I/O will benefit from ioeventfd.  On an
> overcommitted host it could increase guest I/O latency though.  The
> ioeventfd option is currently only supported on virtio-blk (default:
> on) and virtio-net (default: off) devices.
> 
> Please call it ioeventfd.  Also, it can always be toggled using the
> <qemu:commandline> tag if you don't want to expose it natively in
> domain XML.

However, use of <qemu:commandline> results in an unsupported
configuration; we need to expose it natively in domain XML under some
name or another.

We already have the XML attribute io="threads|native" in the same
<driver> element, for selecting whether to use the aio flag for a given
disk driver, so this would not be the first case of selecting a
different name in the XML.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110519/23ac8502/attachment-0001.sig>