From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: assign-dev: Purpose of interrupt_work Date: Mon, 12 Oct 2009 10:39:09 +0200 Message-ID: <4AD2EB2D.5080909@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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19112 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754624AbZJLIji (ORCPT ); Mon, 12 Oct 2009 04:39:38 -0400 In-Reply-To: <4AD2DFE2.4050406@web.de> Sender: kvm-owner@vger.kernel.org List-ID: 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). -- error compiling committee.c: too many arguments to function