From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDdz3-000870-AI for qemu-devel@nongnu.org; Thu, 26 Nov 2009 08:02:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDdyx-00080b-Hu for qemu-devel@nongnu.org; Thu, 26 Nov 2009 08:02:03 -0500 Received: from [199.232.76.173] (port=54216 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDdyx-000807-1O for qemu-devel@nongnu.org; Thu, 26 Nov 2009 08:01:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:65055) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDdyv-000423-9F for qemu-devel@nongnu.org; Thu, 26 Nov 2009 08:01:58 -0500 Date: Thu, 26 Nov 2009 14:59:10 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH 0/4] pci: interrupt status/interrupt disable support Message-ID: <20091126125910.GA31731@redhat.com> References: <20091125165834.GA24783@redhat.com> <20091126032146.GH25483%yamahata@valinux.co.jp> <20091126094811.GB26861@redhat.com> <200911261241.04148.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911261241.04148.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Isaku Yamahata , qemu-devel@nongnu.org On Thu, Nov 26, 2009 at 12:41:03PM +0000, Paul Brook wrote: > > No, this would slow us down because these are per-pin. > > We need a sum of interrupts so that config space > > can be updated by a single command. > > Interrupts are a fastpath, extra loops there should be avoided. > > It's really not that much of a fast path. Unless you're doing something > particularly obscure then even under heavy load you're unlikely to exceed a > few kHz. I think with kvm, heavy disk stressing benchmark can get higher. > Compared to the average PIC implementation, and the overhead of the > actual CPU interrupt, I find it hard to believe that looping over precisely 4 > entries has any real performance hit. > > Paul I don't think it is major, but I definitely have seen, in the past, that extra branches and memory accesses have small but measureable effect when taken in interrupt handler routines in drivers, and same should apply here. OTOH keeping the sum around is trivial. It might not be easily measureable now, but IMO that's just because the whole interrupt delivery is so complex. E.g. we currently have there a loop re-computing interrupt routing on each access, this is just silly and I intend to fix it. I would rather not introduce more code that will have to be cleaned up later. -- MST