From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [RFC] Next gen kvm api Date: Wed, 15 Feb 2012 15:47:15 +0200 Message-ID: <4F3BB763.9080006@redhat.com> References: <4F2AB552.2070909@redhat.com> <4F2E80A7.5040908@redhat.com> <4F3025FB.1070802@codemonkey.ws> <4F31132F.3010100@redhat.com> <4F31408F.80901@codemonkey.ws> <4F314B2A.4000709@redhat.com> <4F314F2C.4040100@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rob Earhart , linux-kernel , KVM list , qemu-devel To: Anthony Liguori Return-path: In-Reply-To: <4F314F2C.4040100@codemonkey.ws> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 02/07/2012 06:19 PM, Anthony Liguori wrote: >> Ah. But then ioeventfd has that as well, unless the other end is in >> the kernel too. > > > Yes, that was my point exactly :-) > > ioeventfd/mmio-over-socketpair to adifferent thread is not faster than > a synchronous KVM_RUN + writing to an eventfd in userspace modulo a > couple of cheap syscalls. > > The exception is when the other end is in the kernel and there is > magic optimizations (like there is today with ioeventfd). vhost seems to schedule a workqueue item unconditionally. irqfd does have magic optimizations to avoid an extra schedule. -- error compiling committee.c: too many arguments to function