qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled()
@ 2014-12-26  8:05 Tiejun Chen
  2014-12-26 10:00 ` Peter Maydell
  0 siblings, 1 reply; 6+ messages in thread
From: Tiejun Chen @ 2014-12-26  8:05 UTC (permalink / raw)
  To: pbonzini; +Cc: qemu-trivial, qemu-devel, kvm

We should avoid to set irqfd{} unconditionally.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
 kvm-all.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 18cc6b4..5b9786b 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1257,21 +1257,21 @@ int kvm_irqchip_update_msi_route(KVMState *s, int virq, MSIMessage msg)
 static int kvm_irqchip_assign_irqfd(KVMState *s, int fd, int rfd, int virq,
                                     bool assign)
 {
-    struct kvm_irqfd irqfd = {
-        .fd = fd,
-        .gsi = virq,
-        .flags = assign ? 0 : KVM_IRQFD_FLAG_DEASSIGN,
-    };
+    struct kvm_irqfd irqfd = {};
+
+    if (!kvm_irqfds_enabled()) {
+        return -ENOSYS;
+    }
+
+    irqfd.fd = fd;
+    irqfd.gsi = virq;
+    irqfd.flags = assign ? 0 : KVM_IRQFD_FLAG_DEASSIGN;
 
     if (rfd != -1) {
         irqfd.flags |= KVM_IRQFD_FLAG_RESAMPLE;
         irqfd.resamplefd = rfd;
     }
 
-    if (!kvm_irqfds_enabled()) {
-        return -ENOSYS;
-    }
-
     return kvm_vm_ioctl(s, KVM_IRQFD, &irqfd);
 }
 
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled()
  2014-12-26  8:05 [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled() Tiejun Chen
@ 2014-12-26 10:00 ` Peter Maydell
  2014-12-26 10:16   ` Denis V. Lunev
  0 siblings, 1 reply; 6+ messages in thread
From: Peter Maydell @ 2014-12-26 10:00 UTC (permalink / raw)
  To: Tiejun Chen; +Cc: QEMU Trivial, Paolo Bonzini, QEMU Developers, kvm-devel

On 26 December 2014 at 08:05, Tiejun Chen <tiejun.chen@intel.com> wrote:
> We should avoid to set irqfd{} unconditionally.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>

Is there a hot path that we use this on such that the difference
in code order matters at all?

thanks
-- PMM

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled()
  2014-12-26 10:00 ` Peter Maydell
@ 2014-12-26 10:16   ` Denis V. Lunev
  2014-12-26 17:59     ` Peter Maydell
  0 siblings, 1 reply; 6+ messages in thread
From: Denis V. Lunev @ 2014-12-26 10:16 UTC (permalink / raw)
  To: Peter Maydell, Tiejun Chen
  Cc: QEMU Trivial, Paolo Bonzini, QEMU Developers, kvm-devel

On 26/12/14 13:00, Peter Maydell wrote:
> On 26 December 2014 at 08:05, Tiejun Chen <tiejun.chen@intel.com> wrote:
>> We should avoid to set irqfd{} unconditionally.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>
> Is there a hot path that we use this on such that the difference
> in code order matters at all?
>
> thanks
> -- PMM
>

IMHO the patch does not change anything even on hot-hot path.
the declaration 'struct kvm_irqfd irqfd = {};' will
result in memset inside.

Thus in order to achieve declared goal author should
declare
    struct kvm_irqfd irqfd;
and perform
    memset(&irqfd, 0, sizeof(irqfd));
later after the check.

Regards,
	Den

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled()
  2014-12-26 10:16   ` Denis V. Lunev
@ 2014-12-26 17:59     ` Peter Maydell
  2014-12-27 14:52       ` Paolo Bonzini
  0 siblings, 1 reply; 6+ messages in thread
From: Peter Maydell @ 2014-12-26 17:59 UTC (permalink / raw)
  To: Denis V. Lunev
  Cc: QEMU Trivial, Tiejun Chen, QEMU Developers, kvm-devel,
	Paolo Bonzini

On 26 December 2014 at 10:16, Denis V. Lunev <den-lists@parallels.com> wrote:
> IMHO the patch does not change anything even on hot-hot path.
> the declaration 'struct kvm_irqfd irqfd = {};' will
> result in memset inside.
>
> Thus in order to achieve declared goal author should
> declare
>    struct kvm_irqfd irqfd;
> and perform
>    memset(&irqfd, 0, sizeof(irqfd));
> later after the check.

Mm, but once you're into such microoptimisations as this you really
need to have a good justification for the effort, in the form of
profiling measurements that indicate that this is a hot path.
In this case that seems pretty unlikely, because I'd expect all
the systems where we care about performance will support irqfds,
so we won't be taking the early-exit code path anyhow. (And
not supporting irqfds is leaving much more performance on the
table than we could possibly be talking about in this function.)

thanks
-- PMM

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled()
  2014-12-26 17:59     ` Peter Maydell
@ 2014-12-27 14:52       ` Paolo Bonzini
  2014-12-29  1:31         ` Chen, Tiejun
  0 siblings, 1 reply; 6+ messages in thread
From: Paolo Bonzini @ 2014-12-27 14:52 UTC (permalink / raw)
  To: Peter Maydell, Denis V. Lunev
  Cc: QEMU Trivial, Tiejun Chen, QEMU Developers, kvm-devel



On 26/12/2014 18:59, Peter Maydell wrote:
> Mm, but once you're into such microoptimisations as this you really
> need to have a good justification for the effort, in the form of
> profiling measurements that indicate that this is a hot path.
> In this case that seems pretty unlikely, because I'd expect all
> the systems where we care about performance will support irqfds,
> so we won't be taking the early-exit code path anyhow. (And
> not supporting irqfds is leaving much more performance on the
> table than we could possibly be talking about in this function.)

Also, it's even possible for a compiler to figure this out.  All in all,
I don't see any advantage to this patch...

Paolo

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled()
  2014-12-27 14:52       ` Paolo Bonzini
@ 2014-12-29  1:31         ` Chen, Tiejun
  0 siblings, 0 replies; 6+ messages in thread
From: Chen, Tiejun @ 2014-12-29  1:31 UTC (permalink / raw)
  To: Paolo Bonzini, Peter Maydell, Denis V. Lunev
  Cc: QEMU Trivial, QEMU Developers, kvm-devel


On 2014/12/27 22:52, Paolo Bonzini wrote:
>
>
> On 26/12/2014 18:59, Peter Maydell wrote:
>> Mm, but once you're into such microoptimisations as this you really
>> need to have a good justification for the effort, in the form of
>> profiling measurements that indicate that this is a hot path.
>> In this case that seems pretty unlikely, because I'd expect all
>> the systems where we care about performance will support irqfds,
>> so we won't be taking the early-exit code path anyhow. (And
>> not supporting irqfds is leaving much more performance on the
>> table than we could possibly be talking about in this function.)
>
> Also, it's even possible for a compiler to figure this out.  All in all,
> I don't see any advantage to this patch...
>

Indeed, its just a cleanup to make codes readable and comprehensible 
since oftentimes we don't initially write such a subsequent code just 
because we have this possibility to figure them out by the compiler, or 
others. And this is why I'm CCing Qemu trivial.

Tiejun

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-12-29  1:31 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-26  8:05 [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled() Tiejun Chen
2014-12-26 10:00 ` Peter Maydell
2014-12-26 10:16   ` Denis V. Lunev
2014-12-26 17:59     ` Peter Maydell
2014-12-27 14:52       ` Paolo Bonzini
2014-12-29  1:31         ` Chen, Tiejun

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).