All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: "gleb@redhat.com" <gleb@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"avi.kivity@gmail.com" <avi.kivity@gmail.com>,
	"Herongguang (Stephen)" <herongguang.he@huawei.com>,
	"Huangweidong (C)" <weidong.huang@huawei.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [RFC]Two ideas to optimize updating irq routing table
Date: Wed, 26 Mar 2014 10:37:54 +0100	[thread overview]
Message-ID: <53329FF2.5040706@redhat.com> (raw)
In-Reply-To: <33183CC9F5247A488A2544077AF19020815DAEBA@SZXEMA503-MBS.china.huawei.com>

Il 26/03/2014 09:22, Gonglei (Arei) ha scritto:
> Yes, previously I was using synchronize_srcu, which is not good. When I
> changed it to synchronize_srcu_expedited, grace period delay is much better
> than synchronize_srcu. Though in our tests, we can still see some impact
> of KVM_SET_GSI_ROUTING ioctl.
>
> Our testing scenario is like this. In VM we run a script that sets smp_affinity
> for each IRQ every 0.5s (this leads QEMU to do KVM_SET_GSI_ROUTING ioctl).
> Outside the VM we ping that VM.

Does the affinity actually change every 0.5s?

> Without patches, ping time can jump from 0.3ms to 2ms-30ms. With synchronize_srcu
> patch, ping time is worse. With synchronize_srcu_expedited patch, ping time is
> overall good, though sometimes ping time jump to 1ms-3ms.
>
> With following raw patch, ping time is like call_rcu patch, that not influenced
> by setting IRQ affinity, keeps 0.3ms, and there is no vulnerability, frequent
> intermidiate KVM_SET_GSI_ROUTING settings are just skipped, and always the newest
> setting would take effect.

Interesting, but it only works for assigned-dev.c which is deprecated. 
If you used VFIO you'd see no improvement, and Christian's s390 usecase 
would also see no improvement.

Paolo

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: "Huangweidong (C)" <weidong.huang@huawei.com>,
	"gleb@redhat.com" <gleb@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	"avi.kivity@gmail.com" <avi.kivity@gmail.com>,
	"Herongguang (Stephen)" <herongguang.he@huawei.com>
Subject: Re: [Qemu-devel] [RFC]Two ideas to optimize updating irq routing table
Date: Wed, 26 Mar 2014 10:37:54 +0100	[thread overview]
Message-ID: <53329FF2.5040706@redhat.com> (raw)
In-Reply-To: <33183CC9F5247A488A2544077AF19020815DAEBA@SZXEMA503-MBS.china.huawei.com>

Il 26/03/2014 09:22, Gonglei (Arei) ha scritto:
> Yes, previously I was using synchronize_srcu, which is not good. When I
> changed it to synchronize_srcu_expedited, grace period delay is much better
> than synchronize_srcu. Though in our tests, we can still see some impact
> of KVM_SET_GSI_ROUTING ioctl.
>
> Our testing scenario is like this. In VM we run a script that sets smp_affinity
> for each IRQ every 0.5s (this leads QEMU to do KVM_SET_GSI_ROUTING ioctl).
> Outside the VM we ping that VM.

Does the affinity actually change every 0.5s?

> Without patches, ping time can jump from 0.3ms to 2ms-30ms. With synchronize_srcu
> patch, ping time is worse. With synchronize_srcu_expedited patch, ping time is
> overall good, though sometimes ping time jump to 1ms-3ms.
>
> With following raw patch, ping time is like call_rcu patch, that not influenced
> by setting IRQ affinity, keeps 0.3ms, and there is no vulnerability, frequent
> intermidiate KVM_SET_GSI_ROUTING settings are just skipped, and always the newest
> setting would take effect.

Interesting, but it only works for assigned-dev.c which is deprecated. 
If you used VFIO you'd see no improvement, and Christian's s390 usecase 
would also see no improvement.

Paolo

  reply	other threads:[~2014-03-26  9:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-25  3:19 [RFC]Two ideas to optimize updating irq routing table Gonglei (Arei)
2014-03-25  3:19 ` [Qemu-devel] " Gonglei (Arei)
2014-03-25 12:37 ` Paolo Bonzini
2014-03-25 12:37   ` [Qemu-devel] " Paolo Bonzini
2014-03-26  8:16   ` Christian Borntraeger
2014-03-26  8:16     ` [Qemu-devel] " Christian Borntraeger
2014-03-26  8:39     ` Gonglei (Arei)
2014-03-26  8:39       ` [Qemu-devel] " Gonglei (Arei)
2014-03-26  8:22   ` Gonglei (Arei)
2014-03-26  8:22     ` [Qemu-devel] " Gonglei (Arei)
2014-03-26  9:37     ` Paolo Bonzini [this message]
2014-03-26  9:37       ` Paolo Bonzini
2014-03-26 11:14     ` Christian Borntraeger
2014-03-26 11:14       ` [Qemu-devel] " Christian Borntraeger
2014-03-26 11:45     ` Michael S. Tsirkin
2014-03-26 11:45       ` [Qemu-devel] " Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53329FF2.5040706@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=arei.gonglei@huawei.com \
    --cc=avi.kivity@gmail.com \
    --cc=borntraeger@de.ibm.com \
    --cc=gleb@redhat.com \
    --cc=herongguang.he@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=weidong.huang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.