From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: assign-dev: Purpose of interrupt_work
Date: Mon, 12 Oct 2009 11:38:31 +0200
Message-ID: <20091012093831.GB16702@redhat.com>
References: <4AD2DA57.6030006@web.de>
 <20091012074513.GV16702@redhat.com>
 <4AD2DFE2.4050406@web.de>
 <20091012075715.GW16702@redhat.com>
 <4AD2E5F8.4070107@web.de>
 <20091012083913.GX16702@redhat.com>
 <4AD2F117.7000403@web.de>
 <4AD2F37A.3060600@redhat.com>
 <4AD2F601.2050207@web.de>
 <4AD2F722.4030605@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Jan Kiszka <jan.kiszka@web.de>, kvm-devel <kvm@vger.kernel.org>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:55491 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755454AbZJLJjA (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 12 Oct 2009 05:39:00 -0400
Content-Disposition: inline
In-Reply-To: <4AD2F722.4030605@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Mon, Oct 12, 2009 at 11:30:10AM +0200, Avi Kivity wrote:
> On 10/12/2009 11:25 AM, Jan Kiszka wrote:
> >>>Or what is the
> >>>alternative?
> >>>
> >>irqfd (which only supports edge-triggered interrupts now).  Note irqfd
> >>needs the same love, it uses a workqueue as well.
> >>
> >>The theory is:
> >>  fd1 = eventfd()
> >>  give fd1 to kvm as irqfd, vhost-net as trigger fd
> >>  fd2 = eventfd()
> >>  give fd2 to kvm as irqfd, uio as trigger fd
> >>  fd3 = evenfd()
> >>  give fd3 to kvm as irqfd, another kvm as ioeventfd
> >>
> >>One interface, multiple users (in the kernel, userspace, or other
> >>processes)
> >I see to overall gain, but likely only worsens my objective (low
> >latency), at least it doesn't improve it.
> 
> irqfd can work from interrupt context, so if we only use the
> workqueue for the many-vcpu cases, we should be fine.
> 
> I think we can do it cleanly, too: in ioapic code, if we're talking
> to one vcpu, wake it immediately; otherwise schedule work to
> continue in process context.  This was the common code can always
> work in interrupt context and not worry about the work queue.
> 
Even if we are talking to one cpu locking is still needed, so unless we
make it spinlock we can't inject from irq context. If we change mutex to
spinlock what is the point of work queue?

--
			Gleb.