All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
	laijs@cn.fujitsu.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
	josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org,
	dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com,
	fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com,
	arjan@linux.intel.com
Subject: Re: [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace periods
Date: Fri, 20 Feb 2015 09:14:42 -0800	[thread overview]
Message-ID: <20150220171442.GM5745@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150220165409.GU5029@twins.programming.kicks-ass.net>

On Fri, Feb 20, 2015 at 05:54:09PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 20, 2015 at 08:37:37AM -0800, Paul E. McKenney wrote:
> > On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
> > > So I though we wanted to get rid / limit the expedited stuff because its
> > > IPI happy, and here its spreading.
> > 
> > Well, at least it no longer IPIs idle CPUs.  ;-)
> > 
> > And this is during boot, when a few extra IPIs should not be a big deal.
> 
> Well the one application now is during boot; but you expose the
> interface for all to use, and therefore someone will.

I could make rcu_expedite_gp() and rcu_unexpedite_gp() be static,
I suppose.  Except that I need to test them with rcutorture.
I suppose I could put the declaration in rcutorture.c, but then
0day will tell me to made them static.  :-/

> > > Does it really make a machine boot much faster? Why are people using
> > > synchronous gp primitives if they care about speed? Should we not fix
> > > that instead?
> > 
> > The report I heard was that it provided 10-15% faster boot times.
> 
> That's not insignificant; got more details? I think we should really
> look at why people are using the sync primitives.

I must defer to the people who took the exact measurements.

But yes, once I have that info, I should add it to the commit log.

							Thanx, Paul


  reply	other threads:[~2015-02-20 17:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-20  5:08 [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace periods Paul E. McKenney
2015-02-20  5:09 ` [PATCH v2 RFC tip/core/rcu 1/4] rcu: Provide rcu_expedite_gp() and rcu_unexpedite_gp() Paul E. McKenney
2015-02-20  5:09   ` [PATCH v2 RFC tip/core/rcu 2/4] rcu: Add rcu_expedite_gp() and rcu_unexpedite_gp() to rcutorture Paul E. McKenney
2015-02-20  5:09   ` [PATCH v2 RFC tip/core/rcu 3/4] rcu: Update from rcu_expedited variable to rcu_gp_is_expedited() Paul E. McKenney
2015-02-20  5:09   ` [PATCH v2 RFC tip/core/rcu 4/4] rcu: Add Kconfig option to expedite grace periods during boot Paul E. McKenney
2015-02-20  9:11 ` [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace periods Peter Zijlstra
2015-02-20 16:37   ` Paul E. McKenney
2015-02-20 16:54     ` Peter Zijlstra
2015-02-20 17:14       ` Paul E. McKenney [this message]
2015-02-20 17:32         ` Arjan van de Ven
2015-02-20 17:43           ` Peter Zijlstra
2015-02-20 17:45             ` Arjan van de Ven
2015-02-21 16:08               ` Peter Zijlstra
2015-02-22  1:43                 ` Paul E. McKenney
2015-02-20 18:38             ` Paul E. McKenney
2015-02-21 16:11               ` Peter Zijlstra
2015-02-21 17:59                 ` Paul E. McKenney
2015-02-20 18:27           ` Paul E. McKenney
2015-02-20 18:29             ` Arjan van de Ven
2015-02-20 18:39               ` Paul E. McKenney
2015-02-21 15:51             ` Arjan van de Ven
2015-02-21 18:00               ` Paul E. McKenney
2015-02-22  3:58               ` Josh Triplett
2015-02-22  6:10                 ` Paul E. McKenney
2015-02-22 18:31                 ` Arjan van de Ven
2015-02-22 18:48                   ` Josh Triplett
2015-02-21  6:04       ` Josh Triplett
2015-02-21 15:12         ` Mathieu Desnoyers
2015-02-21 23:58           ` Paul E. McKenney

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=20150220171442.GM5745@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=bobby.prani@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=dvhart@linux.intel.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.