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 tip/core/rcu 0/10] Reduce latency impact of PREEMPT_RCU CPU offline
Date: Wed, 5 Nov 2014 09:41:09 -0800 [thread overview]
Message-ID: <20141105174109.GA1306@linux.vnet.ibm.com> (raw)
Hello!
This series reduces worst-case CPU-hotplug latency for PREEMPT_RCU
by avoiding an O(N) list move, where N is the number of threads that
were preempted recently while in an RCU read-side critical section.
This situation is rare, occurring only when the last CPU corresponding
to a given rcu_node structure goes offline, for example, when CPUs 1-14
are all offline and CPU 15 goes offline. In this case, all the tasks
that were recently preempted while running on one of CPUs 0-15 will be
moved to the root rcu_node structure. Because this could be a very large
number of tasks, and because this moving is carried out with interrupts
disabled, a very large latency spike can result. This series therefore
reworks RCU's CPU-hotplug code and grace-period computation to remove
the need for moving tasks.
Because there was an obscure bug in the task-move process, this change
also fixes that bug by annihilating the function containing it. This bug
manifests only when RCU priority boosting is enabled, and even then occurs
only roughly once per hundred hours or so of focused rcutorture testing.
It was made somewhat more probable by a recent change to rcutorture
that registers 60,000 RCU callbacks in three batches of 20,000 each,
with one jiffy between each batch.
The individual commits in this series are as follows:
1. Fix a comment: softirqs are disabled, not interrupts.
2. Apply ACCESS_ONCE to rcu_boost().
3. Change rcu_read_unlock_special()'s "empty" variable's name to
"empty_norm" to make room for a new "empty" that will track
the emptiness of the full list rather than just that part that
is blocking the current normal (non-expedited) grace period.
4. Abstract rcu_cleanup_dead_rnp() from rcu_cleanup_dead_cpu().
The new rcu_cleanup_dead_rnp() function clears ->qsmaskinit bits
up the rcu_node tree to allow for the last CPU in a given leaf
rcu_node structure going offline. This function will be called
from rcu_read_unlock_special() when the last blocked task exits
its outermost RCU read-side critical section.
5. Make rcu_read_unlock_special() to propagate ->qsmaskinit bit
clearing up the rcu_node tree once the last task has exited
its RCU read-side critical section.
6. Stop migrating the list of blocked tasks to the root rcu_node
structure.
7. Stop holding the irq-disabled ->orphan_lock across the
->qsmaskinit bit-clearing process, thus reducing the length
of time that interrupts are disabled.
8. Make use of the new rcu_preempt_has_tasks() function.
9. Stop creating an rcub kthread for the root rcu_node structure,
which no longer has tasks in its ->blkd_tasks list (unless it
is also the sole leaf rcu_node structure).
10. Drop the code from force_qs_rnp() that attempts to awaken the
now-nonexistent root rcu_node structure's rcub kthread.
Thanx, Paul
------------------------------------------------------------------------
b/kernel/rcu/tree.c | 103 ++++++++++++++++-------------
b/kernel/rcu/tree.h | 13 ---
b/kernel/rcu/tree_plugin.h | 159 +++++++++++----------------------------------
3 files changed, 98 insertions(+), 177 deletions(-)
next reply other threads:[~2014-11-05 17:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 17:41 Paul E. McKenney [this message]
2014-11-05 17:41 ` [PATCH tip/core/rcu 01/10] rcu: Fix invoke_rcu_callbacks() comment Paul E. McKenney
2014-11-05 17:41 ` [PATCH tip/core/rcu 02/10] rcu: Protect rcu_boost() lockless accesses with ACCESS_ONCE() Paul E. McKenney
2014-11-05 17:41 ` [PATCH tip/core/rcu 03/10] rcu: Rename "empty" to "empty_norm" in preparation for boost rework Paul E. McKenney
2014-11-05 17:41 ` [PATCH tip/core/rcu 04/10] rcu: Abstract rcu_cleanup_dead_rnp() from rcu_cleanup_dead_cpu() Paul E. McKenney
2014-11-05 17:41 ` [PATCH tip/core/rcu 05/10] rcu: Make rcu_read_unlock_special() propagate ->qsmaskinit bit clearing Paul E. McKenney
2014-11-05 17:41 ` [PATCH tip/core/rcu 06/10] rcu: Don't migrate blocked tasks even if all corresponding CPUs offline Paul E. McKenney
2014-11-05 17:41 ` [PATCH tip/core/rcu 07/10] rcu: Shorten irq-disable region in rcu_cleanup_dead_cpu() Paul E. McKenney
2014-11-05 17:41 ` [PATCH tip/core/rcu 08/10] rcu: Make use of rcu_preempt_has_tasks() Paul E. McKenney
2014-11-05 17:41 ` [PATCH tip/core/rcu 09/10] rcu: Don't spawn rcub kthreads on root rcu_node structure Paul E. McKenney
2014-11-05 17:41 ` [PATCH tip/core/rcu 10/10] rcu: Don't initiate RCU priority boosting on root rcu_node 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=20141105174109.GA1306@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 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.