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 11:05:10 +0200 Message-ID: <20091012090509.GZ16702@redhat.com> References: <4AD2D4B6.7030203@web.de> <20091012071310.GT16702@redhat.com> <4AD2DA57.6030006@web.de> <20091012074513.GV16702@redhat.com> <4AD2DFE2.4050406@web.de> <4AD2EB2D.5080909@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kiszka , kvm-devel To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:25320 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754780AbZJLJFi (ORCPT ); Mon, 12 Oct 2009 05:05:38 -0400 Content-Disposition: inline In-Reply-To: <4AD2EB2D.5080909@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Oct 12, 2009 at 10:39:09AM +0200, Avi Kivity wrote: > On 10/12/2009 09:50 AM, Jan Kiszka wrote: > >>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. > > I'm worried about disabling irqs for non-device-assignment cases. > It would be more palatable if ioapic was completely O(1) (there are > some per-vcpu loops in there, shouldn't be too bad for 16 vcpus, but > we want to scale). > We can change it to hash for directed irqs (still not O(1)), but for broadcast irq the loop will be required. -- Gleb.