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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
