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 <mst@xxxxxxxxxx> >>> --- >>> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
