Skip to contentSkip to conversation

kvm: do not flush after deleting gsi

PATCH In review Michael S. Tsirkin 3 participants 5 messages Dec 12, 2012 – Dec 14, 2012 KVM

lore
Share & tools
lore

Michael S. Tsirkin

author
#0 lore raw

PATCH 1/1 kvm: do not flush after deleting gsi

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 <[email protected]>
---
 kvm-all.c | 2 --
 1 file changed, 2 deletions(-)
kvm-all.c +0 -2
index 3bc3347..fb3180d 100644
@@ -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)
Signature · 1 line
MST
Reviewed-by on v1 1/1
#1 lore raw
Quoted 14 lines · Michael S. Tsirkin

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 <[email protected]>
---
 kvm-all.c | 2 --
 1 file changed, 2 deletions(-)
kvm-all.c +0 -0
index 3bc3347..fb3180d 100644

kvm-all.c void kvm_irqchip_release_virq(KVMState *s, int virq) · line 996

Quoted 8 lines
kvm-all.c +0 -2
@@ -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 <[email protected]>
Signature · 2 lines
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
#2 lore raw
In reply to Michael S. Tsirkin

Hello Michael,

Quoted 14 lines · Michael S. Tsirkin

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 <[email protected]>
---
 kvm-all.c | 2 --
 1 file changed, 2 deletions(-)
kvm-all.c +0 -0
index 3bc3347..fb3180d 100644

kvm-all.c void kvm_irqchip_release_virq(KVMState *s, int virq) · line 996

Quoted 8 lines
kvm-all.c +0 -2
@@ -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
Signature · 1 line
Asias
#3 lore raw
Quoted 31 lines · Asias He

Hello Michael,

Quoted 14 lines · Michael S. Tsirkin

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 <[email protected]>
---
 kvm-all.c | 2 --
 1 file changed, 2 deletions(-)
kvm-all.c +0 -0
index 3bc3347..fb3180d 100644

kvm-all.c void kvm_irqchip_release_virq(KVMState *s, int virq) · line 996

Quoted 8 lines
kvm-all.c +0 -2
@@ -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

Quoted 8 lines
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

Signature · 2 lines
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
#4 lore raw

Hello Jan,

Quoted 35 lines · Jan Kiszka
Quoted 34 lines · Asias He

Hello Michael,

Quoted 14 lines · Michael S. Tsirkin

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 <[email protected]>
---
 kvm-all.c | 2 --
 1 file changed, 2 deletions(-)
kvm-all.c +0 -0
index 3bc3347..fb3180d 100644

kvm-all.c void kvm_irqchip_release_virq(KVMState *s, int virq) · line 996

Quoted 8 lines
kvm-all.c +0 -2
@@ -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
Quoted 7 lines
Quoted 5 lines

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.

Signature · 1 line
Asias