qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: "Herongguang (Stephen)" <herongguang.he@huawei.com>,
	"Huangweidong (C)" <weidong.huang@huawei.com>,
	"avi.kivity@gmail.com" <avi.kivity@gmail.com>,
	"gleb@redhat.com" <gleb@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>
Subject: Re: [Qemu-devel] [RFC]Two ideas to optimize updating irq routing table
Date: Wed, 26 Mar 2014 09:16:27 +0100	[thread overview]
Message-ID: <53328CDB.4050702@de.ibm.com> (raw)
In-Reply-To: <53317892.2050506@redhat.com>

On 25/03/14 13:37, Paolo Bonzini wrote:
> Il 25/03/2014 04:19, Gonglei (Arei) ha scritto:
>> Based on discussions in:
>> http://lists.gnu.org/archive/html/qemu-devel/2013-11/threads.html#03322
>>
>> About KVM_SET_GSI_ROUTING ioctl, I tested changing RCU to SRCU, but unfortunately
>> it looks like SRCU's grace period is no better than RCU.
> 
> Really?  This is not what Christian Borntraeger claimed at http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/118083 -- in fact, Andrew Theurer is currently testing a variant of that patch and I was going to post it for 3.16.
> 
> Have you tried synchronize_srcu_expedited?  Unlike the RCU variant, you can use this function.

On my system I have HZ=100 and lots of CPUs. So RCUs "every cpu has scheduled"
is certainly slower than SRCUs algorithm
(/*
 * We use an adaptive strategy for synchronize_srcu() and especially for
 * synchronize_srcu_expedited().  We spin for a fixed time period
 * (defined below) to allow SRCU readers to exit their read-side critical
 * sections.  If there are still some readers after 10 microseconds,
 * we repeatedly block for 1-millisecond time periods.  This approach
 * has done well in testing, so there is no need for a config parameter.
 */
)

With HZ==1000 and a NO. CPUs small SRCUs spinning might be in the same delay
range than classic RCU depending on how long the read side critical 
section is (if we move from spinning to blocking)
So using synchronize_srcu_expedited is certainly something to test as it 
increased the spinning time.

Christian

  reply	other threads:[~2014-03-26  8:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-25  3:19 [Qemu-devel] [RFC]Two ideas to optimize updating irq routing table Gonglei (Arei)
2014-03-25 12:37 ` Paolo Bonzini
2014-03-26  8:16   ` Christian Borntraeger [this message]
2014-03-26  8:39     ` Gonglei (Arei)
2014-03-26  8:22   ` Gonglei (Arei)
2014-03-26  9:37     ` Paolo Bonzini
2014-03-26 11:14     ` Christian Borntraeger
2014-03-26 11:45     ` 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=53328CDB.4050702@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=arei.gonglei@huawei.com \
    --cc=avi.kivity@gmail.com \
    --cc=gleb@redhat.com \
    --cc=herongguang.he@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@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 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).