From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjJbh-0002fD-MW for qemu-devel@nongnu.org; Thu, 13 Dec 2012 19:58:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TjJbf-0002h6-1h for qemu-devel@nongnu.org; Thu, 13 Dec 2012 19:58:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjJbe-0002gy-ON for qemu-devel@nongnu.org; Thu, 13 Dec 2012 19:58:26 -0500 Message-ID: <50CA7A3F.1030806@redhat.com> Date: Fri, 14 Dec 2012 09:00:47 +0800 From: Asias He MIME-Version: 1.0 References: <20121212104821.GA6324@redhat.com> <50C95FD7.9040205@redhat.com> <50C9F578.6030302@siemens.com> In-Reply-To: <50C9F578.6030302@siemens.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] kvm: do not flush after deleting gsi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" Hello Jan, On 12/13/2012 11:34 PM, Jan Kiszka wrote: > On 2012-12-13 05:55, Asias He wrote: >> Hello Michael, >> >> On 12/12/2012 06:48 PM, Michael S. Tsirkin wrote: >>> Deleting a GSI isn't necessary: it is enough >>> to stop using it. Delay flush until an entry is used. >>> >>> Signed-off-by: Michael S. Tsirkin >>> --- >>> kvm-all.c | 2 -- >>> 1 file changed, 2 deletions(-) >>> >>> diff --git a/kvm-all.c b/kvm-all.c >>> index 3bc3347..fb3180d 100644 >>> --- a/kvm-all.c >>> +++ b/kvm-all.c >>> @@ -991,8 +991,6 @@ void kvm_irqchip_release_virq(KVMState *s, int virq) >>> } >>> } >>> clear_gsi(s, virq); >>> - >>> - kvm_irqchip_commit_routes(s); >>> } >>> >>> static unsigned int kvm_hash_msi(uint32_t data) >>> >> >> I tried this patch with vhost-blk with qemu-1.3.0 >> 6d6c9f59ca1b1a76ade7ad868bef191818f58819. >> >> Without the drop of msix_fire_vector_notifier in msix_handle_mask_update >> hack >> Before: ~20K IOPS >> After: ~35K IOPS >> >> With the drop of msix_fire_vector_notifier in >> msix_handle_mask_update hack >> Before: ~197K IOPS >> After: ~197K IOPS >> > > Is the guest balancing the IRQ(s) between its vCPUs all the time? Yes. In all of the four the cases (w/o gsi patch, w/o drop of msix_fire_vector_notifier hack), IRQs balanced evenly in all vCPUs. -- Asias