From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: assign-dev: Purpose of interrupt_work Date: Mon, 12 Oct 2009 09:57:15 +0200 Message-ID: <20091012075715.GW16702@redhat.com> References: <4AD2D4B6.7030203@web.de> <20091012071310.GT16702@redhat.com> <4AD2DA57.6030006@web.de> <20091012074513.GV16702@redhat.com> <4AD2DFE2.4050406@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , kvm-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45633 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754560AbZJLH5n (ORCPT ); Mon, 12 Oct 2009 03:57:43 -0400 Content-Disposition: inline In-Reply-To: <4AD2DFE2.4050406@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Oct 12, 2009 at 09:50:58AM +0200, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Mon, Oct 12, 2009 at 09:27:19AM +0200, Jan Kiszka wrote: > >> Gleb Natapov wrote: > >>> On Mon, Oct 12, 2009 at 09:03:18AM +0200, Jan Kiszka wrote: > >>>> Hi, > >>>> > >>>> I was starring at the IRQ delivery path of assigned devices for a while, > >>>> wondering why we have a work queue there. Now, after looking at some > >>>> prehistoric versions, I think the reason is that there once was a mutex > >>>> involved while we now use RCU. Am I right that we could actually drop > >>>> this indirection today? > >>>> > >>> ioapic/pic path still has mutex. If MSIX is used (like it should) we can > >>> drop work queue. > >> I see. Wouldn't it be feasible to convert the fast paths of [io]apic to > >> spinlocks? > >> > > Apic is lockless. For ioapic/pic I used spinlocks initially, but Avi > > prefers mutexes. Theoretically it is possible to make them lockless, > > but code will be complex and eventually more slow, since more then two > > atomic operation will be used on irq injection path. > > Well, lockless is another thing. > > But also converting to spinlocks would indeed add some overhead: > irqsave/restore. But I wonder if this isn't worth it, at least when > looking at the (supposed to be fast) device passthrough scenario which > would be simpler and faster. > Avi's point in favor of mutex is: they are as fast as spinlocks when congested and allows preemption when held. -- Gleb.