On Thu, May 19, 2011 at 11:20 AM, Daniel Veillard <veillard@xxxxxxxxxx> wrote:
> On Thu, May 19, 2011 at 09:44:35AM +0100, Stefan Hajnoczi wrote:
>> On Thu, May 19, 2011 at 8:26 AM, Daniel Veillard <veillard@xxxxxxxxxx> wrote:
>> > On Wed, May 18, 2011 at 04:07:30PM +0800, Daniel Veillard wrote:
>> >> On Tue, May 17, 2011 at 03:56:11PM +0100, Daniel P. Berrange wrote:
>> >> > On Tue, May 17, 2011 at 04:49:17PM +0200, Michal Privoznik wrote:
>> >> > > This feature allows QEMU to achieve higher throughput, but is available
>> >> > > only in recent versions. It is accessible via ioeventfd attribute
>> >> > > with accepting values 'on', 'off'. Only experienced users needs to set
>> >> > > this, because QEMU defaults to 'on', meaning higher performance.
>> >> > > Translates into virtio-{blk|net}-pci.ioeventfd option.
>> >> [...]
>> >> > > + <li>
>> >> > > + The optional <code>ioeventfd</code> attribute enables or disables
>> >> > > + IOEventFD feature for virtqueue notify. The value can be either
>> >> > > + 'on' or 'off'.
>> >> > > + <span class="since">Since 0.9.2 (QEMU and KVM only)</span>
>> >> >
>> >> > This is a qemu specific attribute name & description. IMHO we shouldn't
>> >> > be exposing that directly. Who even knows what effect it actually has
>> >> > on the guests...
>> >>
>> >> Agreed, what is the semantic of this flag, beside allowing to switch
>> >> something in qemu ?
>> >
>> > Just to clarify my answer a bit, the problem here is that the patch
>> > does not explain what the ioeventfd qemu flag does in practice and how
>> > it influence the virtualization. To be able to provide a good API and
>> > maintain it long term we need to be able to explain the semantic of
>> > the API (be it a function of the library or part of the XML being used),
>> > only then we can guarantee that there is no misunderstanding about what
>> > it does, and also allow us to reuse it in case the same functionality
>> > is provided by another hypervisor.
>> > So instead of explaining the option using terms from QEmu, let's
>> > explain what it does in general terms and use those general terms to
>> > model the API,
>>
>> I don't think there is a general API here, ioeventfd is specific to
>> QEMU's architecture. It allows you to switch between two internal
>> threading models for handling I/O emulation. It could change in the
>> future if QEMU's architecture changes. This is not an end-user
>> feature, it's more an internal performance tunable.
>
> Actually reading about it at
> https://patchwork.kernel.org/patch/43390/
>
> it seems that can be described as
> "domain I/O asynchronous handling",
> it's a shortcut because it's not for the whole I/O only a part of it
> but that in itself is sufficiently generic to be potentially useful
> for something else.
>
> I would just suggest to rename the attribute "asyncio" with value
> on or off, document the fact that it allows to force on or off some of
> the asynchronous I/O handling for the device, and that the default is
> left to the discretion of the hypervisor.
>
> 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.
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.
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.
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.
Stefan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list