From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET Date: Wed, 13 Jul 2011 10:07:26 +0300 Message-ID: <4E1D442E.6090308@redhat.com> References: <1309927078-5983-1-git-send-email-levinsasha928@gmail.com> <1309927078-5983-5-git-send-email-levinsasha928@gmail.com> <20110706114203.GA18368@redhat.com> <1309964506.15123.13.camel@sasha> <20110706155135.GA21638@redhat.com> <1310276083.2393.6.camel@sasha> <20110710080559.GC1630@redhat.com> <1310469824.2393.22.camel@sasha> <4E1C2F59.90600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sasha Levin , "Michael S. Tsirkin" , kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti To: Pekka Enberg Return-path: Received: from mx1.redhat.com ([209.132.183.28]:8009 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964998Ab1GMHHo (ORCPT ); Wed, 13 Jul 2011 03:07:44 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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.