public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: 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, peterz@infradead.org,
	rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
	dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com,
	bobby.prani@gmail.com
Subject: [PATCH RFC tip/core/rcu 0/4] Refactor RCU's interactions with CPU hotplug
Date: Thu, 29 Jan 2015 16:19:38 -0800	[thread overview]
Message-ID: <20150130001938.GA29846@linux.vnet.ibm.com> (raw)

Hello!

As promised/threatened for some years now...

This series, perhaps for v3.21, contains changes that allow RCU to more
precisely determine when a CPU goes offline.  This is a nice improvement
over the current state, in which a CPU takes a final pass through the
scheduler after the CPU_DYING notifier.  RCU currently gets around this
imprecision by assuming that it will never take more than one jiffy for
the CPU to make its final pass through the scheduler, which is clearly
an accident waiting to happen, especially in virtualized environments.
This series of changes removes this vulnerability, although the
corresponding window of vulnerability for CPUs coming online remains
and will be addressed at a later date.

The patches in this series are as follows:

1.	Remove the need for the ->onoff_mutex sleeplock by buffering
	CPU online and offline events in a pair of new rcu_node
	bitmasks, ->oflmask and ->onlmask.  These are protected by
	the rcu_node structure's ->lock, which may be acquired from
	preemption-disabled environments such as the idle loop.
	CPU-hotplug races with grace-period initialization are
	eliminated by applying ->oflmask and ->onlmask during the
	early phases of grace-period initialization.  The various
	lockdep-RCU checks for using RCU from an offline CPU are
	updated to allow for the new ->oflmask and ->onlmask bitmasks.

2.	Remove the ->onoff_mutex sleeplock.

3.	Replace the current use of idle_cpu() with a per-CPU cpu_dead_idle
	variable so that powering off the CPU will be deferred until
	just before the outgoing CPU invokes arch_cpu_idle_dead().

4.	Cause the idle loop to invoke rcu_cpu_notify() just before
	the cpu_dead_idle per-CPU variable is set.  Should a more
	organized method of invoking CPU-hotplug notifiers from the idle
	loop appear, this code should clearly be modified to use
	that more organized method.

This passes light rcutorture testing, but probably has a bug or three
remaining.  Interestingly enough, patch #1 above allows RCU to tolerate
some new torture methods that otherwise break it.

							Thanx, Paul

------------------------------------------------------------------------

 b/include/linux/cpu.h      |    2 
 b/include/linux/rcupdate.h |    2 
 b/kernel/cpu.c             |    6 +
 b/kernel/rcu/tree.c        |  209 ++++++++++++++++++++++++++++++++-------------
 b/kernel/rcu/tree.h        |    9 +
 b/kernel/rcu/tree_plugin.h |   24 +----
 b/kernel/rcu/tree_trace.c  |    3 
 b/kernel/sched/idle.c      |    9 +
 8 files changed, 184 insertions(+), 80 deletions(-)


             reply	other threads:[~2015-01-30  0:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-30  0:19 Paul E. McKenney [this message]
2015-01-30  0:20 ` [PATCH RFC tip/core/rcu 1/4] rcu: Process offlining and onlining only at grace-period start Paul E. McKenney
2015-01-30  0:20   ` [PATCH RFC tip/core/rcu 2/4] rcu: Eliminate ->onoff_mutex from rcu_node structure Paul E. McKenney
2015-01-30  0:20   ` [PATCH RFC tip/core/rcu 3/4] cpu: Make CPU-offline idle-loop transition point more precise Paul E. McKenney
2015-01-30  0:20   ` [PATCH RFC tip/core/rcu 4/4] rcu: Handle outgoing CPUs on exit from idle loop Paul E. McKenney
2015-01-30 22:16     ` 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=20150130001938.GA29846@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox