From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: assign-dev: Purpose of interrupt_work Date: Mon, 12 Oct 2009 14:36:51 -0300 Message-ID: <20091012173651.GA3923@amt.cnet> 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> <4AD2F1D0.4090005@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Gleb Natapov , kvm-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:65479 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757397AbZJLRh3 (ORCPT ); Mon, 12 Oct 2009 13:37:29 -0400 Content-Disposition: inline In-Reply-To: <4AD2F1D0.4090005@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Oct 12, 2009 at 11:07:28AM +0200, Jan Kiszka wrote: > 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). > > Yeah, what a pity. That's likely not solvable in a generic way, given > that the guest finally decided how many VCPUs may listen to a line. > > OK, but dropping interrupt_work from the MSI path is still worthwhile, > and probably more future-proof anyway. Seems appropriate to convert the process context work to threaded interrupt (instead of workqueue). That should help latency.