All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Josh Triplett <josht@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
	laijs@cn.fujitsu.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
	dvhltc@us.ibm.com, niv@us.ibm.com, tglx@linutronix.de,
	peterz@infradead.org, rostedt@goodmis.org
Subject: Re: [PATCH -tip] Create rcutree plugins to handle hotplug CPU for multi-level trees
Date: Tue, 25 Aug 2009 16:30:27 -0700	[thread overview]
Message-ID: <20090825233027.GO6616@linux.vnet.ibm.com> (raw)
In-Reply-To: <1251225483.2706.4.camel@josh-work.beaverton.ibm.com>

On Tue, Aug 25, 2009 at 11:38:03AM -0700, Josh Triplett wrote:
> On Tue, 2009-08-25 at 11:22 -0700, Paul E. McKenney wrote:
> > When offlining CPUs from a multi-level tree, there is the possibility
> > of offlining the last CPU from a given node when there are preempted
> > RCU read-side critical sections that started life on one of the CPUs on
> > that node.  In this case, the corresponding tasks will be enqueued via
> > the task_struct's rcu_node_entry list_head onto one of the rcu_node's
> > blocked_tasks[] lists.  These tasks need to be moved somewhere else
> > so that they will prevent the current grace period from ending.
> > That somewhere is the root rcu_node.
> > 
> > With this patch, TREE_PREEMPT_RCU passes moderate rcutorture testing
> > with aggressive CPU-hotplugging (no delay between inserting/removing
> > randomly selected CPU).
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> Looks good.  One comment below.
> 
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -1208,7 +1208,7 @@ struct task_struct {
> >  #ifdef CONFIG_TREE_PREEMPT_RCU
> >  	int rcu_read_lock_nesting;
> >  	char rcu_read_unlock_special;
> > -	int rcu_blocked_cpu;
> > +	void *rcu_blocked_node;
> 
> This should use struct rcu_node *, not void *.  That would eliminate
> several casts in the changes below.  You can forward-declare struct
> rcu_node if you want to avoid including RCU headers in sched.h.

Good point -- it would be nice to avoid the casts.

> > --- a/kernel/rcutree_plugin.h
> > +++ b/kernel/rcutree_plugin.h
> > @@ -92,7 +92,7 @@ static void rcu_preempt_qs(int cpu)
> >  		rnp = rdp->mynode;
> >  		spin_lock(&rnp->lock);
> >  		t->rcu_read_unlock_special |= RCU_READ_UNLOCK_BLOCKED;
> > -		t->rcu_blocked_cpu = cpu;
> > +		t->rcu_blocked_node = (void *)rnp;
> 
> Regardless of whether you change the type in the structure, you never
> need to cast a pointer to type void *; any non-function pointer will
> become void * without complaint.
> 
> > @@ -170,12 +170,21 @@ static void rcu_read_unlock_special(struct task_struct *t)
> >  	if (special & RCU_READ_UNLOCK_BLOCKED) {
> >  		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
> > 
> > -		/* Remove this task from the list it blocked on. */
> > -		rnp = rcu_preempt_state.rda[t->rcu_blocked_cpu]->mynode;
> > -		spin_lock(&rnp->lock);
> > +		/*
> > +		 * Remove this task from the list it blocked on.  The
> > +		 * task can migrate while we acquire the lock, but at
> > +		 * most one time.  So at most two passes through loop.
> > +		 */
> > +		for (;;) {
> > +			rnp = (struct rcu_node *)t->rcu_blocked_node;
> > +			spin_lock(&rnp->lock);
> > +			if (rnp == (struct rcu_node *)t->rcu_blocked_node)
> > +				break;
> > +			spin_unlock(&rnp->lock);
> > +		}
> 
> Both of the casts of t->rcu_blocked_node can go away here, given the
> type change in the structure.

Indeed.  Fixed, will submit early tomorrow.

							Thanx, Paul

  reply	other threads:[~2009-08-25 23:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-25 18:22 [PATCH -tip] Create rcutree plugins to handle hotplug CPU for multi-level trees Paul E. McKenney
2009-08-25 18:38 ` Josh Triplett
2009-08-25 23:30   ` Paul E. McKenney [this message]
2009-08-25 18:48 ` Mathieu Desnoyers
2009-08-25 23:51   ` 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=20090825233027.GO6616@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dipankar@in.ibm.com \
    --cc=dvhltc@us.ibm.com \
    --cc=josht@linux.vnet.ibm.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=niv@us.ibm.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.