diff mbox

kvm: do not flush after deleting gsi

Message ID 20121212104821.GA6324@redhat.com
State New
Headers show

Commit Message

Michael S. Tsirkin Dec. 12, 2012, 10:48 a.m. UTC
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@redhat.com>
---
 kvm-all.c | 2 --
 1 file changed, 2 deletions(-)

Comments

Jan Kiszka Dec. 12, 2012, 11:39 a.m. UTC | #1
On 2012-12-12 11:48, 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@redhat.com>
> ---
>  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)
> 

Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Asias He Dec. 13, 2012, 4:55 a.m. UTC | #2
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@redhat.com>
> ---
>  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
Jan Kiszka Dec. 13, 2012, 3:34 p.m. UTC | #3
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@redhat.com>
>> ---
>>  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?

Jan
Asias He Dec. 14, 2012, 1 a.m. UTC | #4
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@redhat.com>
>>> ---
>>>  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.
diff mbox

Patch

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)