From: Mike Galbraith <efault@gmx.de>
To: paulmck@linux.vnet.ibm.com
Cc: Dimitri Sivanich <sivanich@sgi.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] rcu: Limit GP initialization to CPUs that have been online
Date: Sat, 14 Apr 2012 07:42:55 +0200 [thread overview]
Message-ID: <1334382175.5561.49.camel@marge.simpson.net> (raw)
In-Reply-To: <20120413184228.GC2402@linux.vnet.ibm.com>
On Fri, 2012-04-13 at 11:42 -0700, Paul E. McKenney wrote:
> On Wed, Apr 11, 2012 at 01:04:36PM +0200, Mike Galbraith wrote:
> > Hi Paul (and Dimitri),
> >
> > Just got back to this. I changed the patch around to check for a
> > hotplug event in force_qs_rnp(), and should that happen, process any
> > freshly added CPUs immediately rather than tell the caller to restart
> > from scratch. The rest of the delta is cosmetic, and there should be
> > zero performance change.
> >
> > Does this change address any of your concerns?
>
> Apologies for being slow to respond...
Hey, I'm grateful for any time you have to share.
> One of my main concerns was present in my original patch: I now believe
> that a given grace period needs to operate on the set of rcu_node
> structures (and CPUs) that were present at the beginning of the grace
> period. Otherwise, things could get confused if a given CPU participated
> in an later force_quiescent_state() state, but not in an earlier one.
>
> I believe that the correct way to handle this is to squirrel the maximum
> number of CPUs away in the rcu_state structure at the beginning of each
> grace period and use that as the limit.
>
> I call out a few more below.
Read it, got it. The last node being partially initialized still causes
some head scratching, I'll ponder that more between explosions. Thanks.
-Mike
next prev parent reply other threads:[~2012-04-14 5:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-14 0:24 Paul E. McKenney
2012-03-14 9:24 ` Mike Galbraith
2012-03-14 12:40 ` Mike Galbraith
2012-03-14 13:08 ` Dimitri Sivanich
2012-03-14 15:17 ` Paul E. McKenney
2012-03-14 16:56 ` Paul E. McKenney
2012-03-15 2:42 ` Mike Galbraith
2012-03-15 3:07 ` Mike Galbraith
2012-03-15 17:02 ` Paul E. McKenney
2012-03-15 17:21 ` Dimitri Sivanich
2012-03-16 4:45 ` Mike Galbraith
2012-03-15 17:59 ` Dimitri Sivanich
2012-03-16 7:27 ` Mike Galbraith
2012-03-16 8:09 ` Mike Galbraith
2012-03-16 8:45 ` Mike Galbraith
2012-03-16 17:28 ` Dimitri Sivanich
2012-03-16 17:51 ` Paul E. McKenney
2012-03-16 17:56 ` Dimitri Sivanich
2012-03-16 19:11 ` Mike Galbraith
2012-03-22 15:35 ` Mike Galbraith
2012-03-22 20:24 ` Dimitri Sivanich
2012-03-23 4:48 ` Mike Galbraith
2012-03-23 19:23 ` Paul E. McKenney
2012-04-11 11:04 ` Mike Galbraith
2012-04-13 18:42 ` Paul E. McKenney
2012-04-14 5:42 ` Mike Galbraith [this message]
2012-03-15 17:58 ` Dimitri Sivanich
2012-03-15 18:23 ` Paul E. McKenney
2012-03-15 21:07 ` Paul E. McKenney
2012-03-16 15:46 ` Dimitri Sivanich
2012-03-16 17:21 ` Paul E. McKenney
2012-03-14 17:07 ` Mike Galbraith
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=1334382175.5561.49.camel@marge.simpson.net \
--to=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=sivanich@sgi.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
Powered by JetHome