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:45:13 +0200 Message-ID: <20091012074513.GV16702@redhat.com> References: <4AD2D4B6.7030203@web.de> <20091012071310.GT16702@redhat.com> <4AD2DA57.6030006@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]:13964 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753595AbZJLHpl (ORCPT ); Mon, 12 Oct 2009 03:45:41 -0400 Content-Disposition: inline In-Reply-To: <4AD2DA57.6030006@web.de> Sender: kvm-owner@vger.kernel.org List-ID: 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. -- Gleb.