From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDeI7-0000Jx-52 for qemu-devel@nongnu.org; Thu, 26 Nov 2009 08:21:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDeI2-0000GS-K0 for qemu-devel@nongnu.org; Thu, 26 Nov 2009 08:21:46 -0500 Received: from [199.232.76.173] (port=54107 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDeI1-0000GC-TL for qemu-devel@nongnu.org; Thu, 26 Nov 2009 08:21:42 -0500 Received: from mx20.gnu.org ([199.232.41.8]:15701) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NDeI1-0007NX-LR for qemu-devel@nongnu.org; Thu, 26 Nov 2009 08:21:41 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDeI0-0006jj-MO for qemu-devel@nongnu.org; Thu, 26 Nov 2009 08:21:41 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 0/4] pci: interrupt status/interrupt disable support Date: Thu, 26 Nov 2009 13:21:39 +0000 References: <20091125165834.GA24783@redhat.com> <200911261241.04148.paul@codesourcery.com> <20091126125910.GA31731@redhat.com> In-Reply-To: <20091126125910.GA31731@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200911261321.39347.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Isaku Yamahata , qemu-devel@nongnu.org >> 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. I'd still expect this to be the least of your problems. If nothing else you've at least one host signal delivery and/or thread context switch in there. Not to mention the overhead to forwarding the interrupt to the guest CPU. > > 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. > > 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. Not entirely. You now have two different bits of information that you have to keep consistent. Unless you can show that this is performance critical code I strongly recommend keeping it as simple as possible. Paul