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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list