Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET

[Avi Kivity <avi@redhat.com>]

On 07/13/2011 09:45 AM, Pekka Enberg wrote:
> >
> >  OK, what's the simplest thing we can do here to keep Avi happy and get
> >  the functionality of Sasha's original patch that helps us avoid guest
> >  exits for serial console? I agree with Avi that we don't want
> >  fragmented ABI but it seems to me there's no clear idea how to fix
> >  KVM_IOEVENTFD_FLAG_SOCKET corner cases, right?
>
> And btw, I didn't follow the discussion closely, but introducing a new
> type of exit for a feature that's designed to _avoid exits_ doesn't
> seem like a smart thing to do. Is it even possible to support sockets
> sanely for this?

First of all, this feature doesn't avoid exits.  The guest exits to the 
kernel just the same.  It just avoids userspace exits, trading them off 
for remote wakeups or context switches, as the case may be, which are 
both more expensive.

This feature is a win in the following cases:
- the socket is consumed in the kernel (like ioeventfd/irqfd and 
vhost-net, or vfio)
- the I/O triggers a lot of cpu work, _and_ there is a lot of spare cpu 
available on the host, so we can parallelize work.  Note it ends up 
being less efficient, but delivering higher throughput.  That's common 
in benchmarks but not so good for real workloads.
- the socket is consumed in another process (not thread) in which case 
we gain some security
- the writes are such high frequency that we gain something from the 
queueing is happens when we thread work.  That's where the gain for 
serial console can come from - though it would be better to just use 
virtio-serial instead.

Second, introducing a new type of exit doesn't mean we see more exits.

Third, the new type of exit is probably not needed - we can use the 
existing mmio/pio exits, and document that in certain cases the kernel 
will fall back to these instead of delivering the I/O via the sockets 
(userspace can then try writing itself).

There was a fourth too but I forgot it already.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.