Re: [libvirt] [PATCH v2] qemu: Add option to enable/disable IOEventFD feature
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)