2009-08-23 04:56:45 +08:00
|
|
|
/*
|
|
|
|
|
* Read-Copy Update mechanism for mutual exclusion (tree-based version)
|
|
|
|
|
* Internal non-public definitions.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2013-12-04 02:02:52 +08:00
|
|
|
* along with this program; if not, you can access it online at
|
|
|
|
|
* http://www.gnu.org/licenses/gpl-2.0.html.
|
2009-08-23 04:56:45 +08:00
|
|
|
*
|
|
|
|
|
* Copyright IBM Corporation, 2008
|
|
|
|
|
*
|
|
|
|
|
* Author: Ingo Molnar <mingo@elte.hu>
|
|
|
|
|
* Paul E. McKenney <paulmck@linux.vnet.ibm.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/cache.h>
|
|
|
|
|
#include <linux/spinlock.h>
|
2017-02-03 17:08:30 +08:00
|
|
|
#include <linux/rtmutex.h>
|
2009-08-23 04:56:45 +08:00
|
|
|
#include <linux/threads.h>
|
|
|
|
|
#include <linux/cpumask.h>
|
|
|
|
|
#include <linux/seqlock.h>
|
2016-02-19 16:46:41 +08:00
|
|
|
#include <linux/swait.h>
|
2015-06-26 02:27:10 +08:00
|
|
|
#include <linux/stop_machine.h>
|
2017-03-15 03:42:30 +08:00
|
|
|
#include <linux/rcu_node_tree.h>
|
2012-04-24 06:52:53 +08:00
|
|
|
|
2017-05-02 16:31:18 +08:00
|
|
|
#include "rcu_segcblist.h"
|
|
|
|
|
|
2009-08-23 04:56:45 +08:00
|
|
|
/*
|
|
|
|
|
* Dynticks per-CPU state.
|
|
|
|
|
*/
|
|
|
|
|
struct rcu_dynticks {
|
2017-10-05 06:55:16 +08:00
|
|
|
long dynticks_nesting; /* Track process nesting level. */
|
|
|
|
|
long dynticks_nmi_nesting; /* Track irq/NMI nesting level. */
|
rcu: Track idleness independent of idle tasks
Earlier versions of RCU used the scheduling-clock tick to detect idleness
by checking for the idle task, but handled idleness differently for
CONFIG_NO_HZ=y. But there are now a number of uses of RCU read-side
critical sections in the idle task, for example, for tracing. A more
fine-grained detection of idleness is therefore required.
This commit presses the old dyntick-idle code into full-time service,
so that rcu_idle_enter(), previously known as rcu_enter_nohz(), is
always invoked at the beginning of an idle loop iteration. Similarly,
rcu_idle_exit(), previously known as rcu_exit_nohz(), is always invoked
at the end of an idle-loop iteration. This allows the idle task to
use RCU everywhere except between consecutive rcu_idle_enter() and
rcu_idle_exit() calls, in turn allowing architecture maintainers to
specify exactly where in the idle loop that RCU may be used.
Because some of the userspace upcall uses can result in what looks
to RCU like half of an interrupt, it is not possible to expect that
the irq_enter() and irq_exit() hooks will give exact counts. This
patch therefore expands the ->dynticks_nesting counter to 64 bits
and uses two separate bitfields to count process/idle transitions
and interrupt entry/exit transitions. It is presumed that userspace
upcalls do not happen in the idle loop or from usermode execution
(though usermode might do a system call that results in an upcall).
The counter is hard-reset on each process/idle transition, which
avoids the interrupt entry/exit error from accumulating. Overflow
is avoided by the 64-bitness of the ->dyntick_nesting counter.
This commit also adds warnings if a non-idle task asks RCU to enter
idle state (and these checks will need some adjustment before applying
Frederic's OS-jitter patches (http://lkml.org/lkml/2011/10/7/246).
In addition, validation of ->dynticks and ->dynticks_nesting is added.
Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
2011-10-01 03:10:22 +08:00
|
|
|
atomic_t dynticks; /* Even value for idle, else odd. */
|
2017-01-28 06:17:50 +08:00
|
|
|
bool rcu_need_heavy_qs; /* GP old, need heavy quiescent state. */
|
2017-01-27 08:18:07 +08:00
|
|
|
unsigned long rcu_qs_ctr; /* Light universal quiescent state ctr. */
|
2017-01-28 06:17:50 +08:00
|
|
|
bool rcu_urgent_qs; /* GP old need light quiescent state. */
|
2012-05-10 03:07:05 +08:00
|
|
|
#ifdef CONFIG_RCU_FAST_NO_HZ
|
2012-12-29 03:30:36 +08:00
|
|
|
bool all_lazy; /* Are all CPU's CBs lazy? */
|
2012-05-10 03:07:05 +08:00
|
|
|
unsigned long nonlazy_posted;
|
|
|
|
|
/* # times non-lazy CBs posted to CPU. */
|
|
|
|
|
unsigned long nonlazy_posted_snap;
|
|
|
|
|
/* idle-period nonlazy_posted snapshot. */
|
2012-12-29 03:30:36 +08:00
|
|
|
unsigned long last_accelerate;
|
|
|
|
|
/* Last jiffy CBs were accelerated. */
|
2013-08-26 12:20:47 +08:00
|
|
|
unsigned long last_advance_all;
|
|
|
|
|
/* Last jiffy CBs were all advanced. */
|
2012-06-25 01:15:02 +08:00
|
|
|
int tick_nohz_enabled_snap; /* Previously seen value from sysfs. */
|
2012-05-10 03:07:05 +08:00
|
|
|
#endif /* #ifdef CONFIG_RCU_FAST_NO_HZ */
|
2009-08-23 04:56:45 +08:00
|
|
|
};
|
|
|
|
|
|
2011-03-30 08:48:28 +08:00
|
|
|
/* RCU's kthread states for tracing. */
|
|
|
|
|
#define RCU_KTHREAD_STOPPED 0
|
|
|
|
|
#define RCU_KTHREAD_RUNNING 1
|
|
|
|
|
#define RCU_KTHREAD_WAITING 2
|
2011-04-07 07:01:16 +08:00
|
|
|
#define RCU_KTHREAD_OFFCPU 3
|
|
|
|
|
#define RCU_KTHREAD_YIELDING 4
|
|
|
|
|
#define RCU_KTHREAD_MAX 4
|
2011-03-30 08:48:28 +08:00
|
|
|
|
2009-08-23 04:56:45 +08:00
|
|
|
/*
|
|
|
|
|
* Definition for node within the RCU grace-period-detection hierarchy.
|
|
|
|
|
*/
|
|
|
|
|
struct rcu_node {
|
2015-12-29 12:18:47 +08:00
|
|
|
raw_spinlock_t __private lock; /* Root rcu_node's lock protects */
|
|
|
|
|
/* some rcu_state fields as well as */
|
|
|
|
|
/* following. */
|
2010-02-23 09:05:01 +08:00
|
|
|
unsigned long gpnum; /* Current grace period for this node. */
|
2009-08-28 06:00:12 +08:00
|
|
|
/* This will either be equal to or one */
|
|
|
|
|
/* behind the root rcu_node's gpnum. */
|
2010-02-23 09:05:01 +08:00
|
|
|
unsigned long completed; /* Last GP completed for this node. */
|
2009-11-03 05:52:28 +08:00
|
|
|
/* This will either be equal to or one */
|
|
|
|
|
/* behind the root rcu_node's gpnum. */
|
2009-08-23 04:56:45 +08:00
|
|
|
unsigned long qsmask; /* CPUs or groups that need to switch in */
|
|
|
|
|
/* order for current grace period to proceed.*/
|
2009-09-24 00:50:42 +08:00
|
|
|
/* In leaf rcu_node, each bit corresponds to */
|
|
|
|
|
/* an rcu_data structure, otherwise, each */
|
|
|
|
|
/* bit corresponds to a child rcu_node */
|
|
|
|
|
/* structure. */
|
2009-08-23 04:56:45 +08:00
|
|
|
unsigned long qsmaskinit;
|
2015-08-01 07:04:45 +08:00
|
|
|
/* Per-GP initial value for qsmask. */
|
rcu: Process offlining and onlining only at grace-period start
Races between CPU hotplug and grace periods can be difficult to resolve,
so the ->onoff_mutex is used to exclude the two events. Unfortunately,
this means that it is impossible for an outgoing CPU to perform the
last bits of its offlining from its last pass through the idle loop,
because sleeplocks cannot be acquired in that context.
This commit avoids these problems by buffering online and offline events
in a new ->qsmaskinitnext field in the leaf rcu_node structures. When a
grace period starts, the events accumulated in this mask are applied to
the ->qsmaskinit field, and, if needed, up the rcu_node tree. The special
case of all CPUs corresponding to a given leaf rcu_node structure being
offline while there are still elements in that structure's ->blkd_tasks
list is handled using a new ->wait_blkd_tasks field. In this case,
propagating the offline bits up the tree is deferred until the beginning
of the grace period after all of the tasks have exited their RCU read-side
critical sections and removed themselves from the list, at which point
the ->wait_blkd_tasks flag is cleared. If one of that leaf rcu_node
structure's CPUs comes back online before the list empties, then the
->wait_blkd_tasks flag is simply cleared.
This of course means that RCU's notion of which CPUs are offline can be
out of date. This is OK because RCU need only wait on CPUs that were
online at the time that the grace period started. In addition, RCU's
force-quiescent-state actions will handle the case where a CPU goes
offline after the grace period starts.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2015-01-24 13:52:37 +08:00
|
|
|
/* Initialized from ->qsmaskinitnext at the */
|
|
|
|
|
/* beginning of each grace period. */
|
|
|
|
|
unsigned long qsmaskinitnext;
|
|
|
|
|
/* Online CPUs for next grace period. */
|
2015-08-01 07:04:45 +08:00
|
|
|
unsigned long expmask; /* CPUs or groups that need to check in */
|
|
|
|
|
/* to allow the current expedited GP */
|
|
|
|
|
/* to complete. */
|
|
|
|
|
unsigned long expmaskinit;
|
|
|
|
|
/* Per-GP initial values for expmask. */
|
|
|
|
|
/* Initialized from ->expmaskinitnext at the */
|
|
|
|
|
/* beginning of each expedited GP. */
|
|
|
|
|
unsigned long expmaskinitnext;
|
|
|
|
|
/* Online CPUs for next expedited GP. */
|
2015-09-30 00:45:00 +08:00
|
|
|
/* Any CPU that has ever been online will */
|
|
|
|
|
/* have its bit set. */
|
2017-08-18 08:05:59 +08:00
|
|
|
unsigned long ffmask; /* Fully functional CPUs. */
|
2009-08-23 04:56:45 +08:00
|
|
|
unsigned long grpmask; /* Mask to apply to parent qsmask. */
|
2009-09-24 00:50:42 +08:00
|
|
|
/* Only one bit will be set in this mask. */
|
2009-08-23 04:56:45 +08:00
|
|
|
int grplo; /* lowest-numbered CPU or group here. */
|
|
|
|
|
int grphi; /* highest-numbered CPU or group here. */
|
|
|
|
|
u8 grpnum; /* CPU/group number for next level up. */
|
|
|
|
|
u8 level; /* root is at level 0. */
|
rcu: Process offlining and onlining only at grace-period start
Races between CPU hotplug and grace periods can be difficult to resolve,
so the ->onoff_mutex is used to exclude the two events. Unfortunately,
this means that it is impossible for an outgoing CPU to perform the
last bits of its offlining from its last pass through the idle loop,
because sleeplocks cannot be acquired in that context.
This commit avoids these problems by buffering online and offline events
in a new ->qsmaskinitnext field in the leaf rcu_node structures. When a
grace period starts, the events accumulated in this mask are applied to
the ->qsmaskinit field, and, if needed, up the rcu_node tree. The special
case of all CPUs corresponding to a given leaf rcu_node structure being
offline while there are still elements in that structure's ->blkd_tasks
list is handled using a new ->wait_blkd_tasks field. In this case,
propagating the offline bits up the tree is deferred until the beginning
of the grace period after all of the tasks have exited their RCU read-side
critical sections and removed themselves from the list, at which point
the ->wait_blkd_tasks flag is cleared. If one of that leaf rcu_node
structure's CPUs comes back online before the list empties, then the
->wait_blkd_tasks flag is simply cleared.
This of course means that RCU's notion of which CPUs are offline can be
out of date. This is OK because RCU need only wait on CPUs that were
online at the time that the grace period started. In addition, RCU's
force-quiescent-state actions will handle the case where a CPU goes
offline after the grace period starts.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2015-01-24 13:52:37 +08:00
|
|
|
bool wait_blkd_tasks;/* Necessary to wait for blocked tasks to */
|
|
|
|
|
/* exit RCU read-side critical sections */
|
|
|
|
|
/* before propagating offline up the */
|
|
|
|
|
/* rcu_node tree? */
|
2009-08-23 04:56:45 +08:00
|
|
|
struct rcu_node *parent;
|
2010-11-30 13:56:39 +08:00
|
|
|
struct list_head blkd_tasks;
|
|
|
|
|
/* Tasks blocked in RCU read-side critical */
|
|
|
|
|
/* section. Tasks are placed at the head */
|
|
|
|
|
/* of this list and age towards the tail. */
|
|
|
|
|
struct list_head *gp_tasks;
|
|
|
|
|
/* Pointer to the first task blocking the */
|
|
|
|
|
/* current grace period, or NULL if there */
|
|
|
|
|
/* is no such task. */
|
|
|
|
|
struct list_head *exp_tasks;
|
|
|
|
|
/* Pointer to the first task blocking the */
|
|
|
|
|
/* current expedited grace period, or NULL */
|
|
|
|
|
/* if there is no such task. If there */
|
|
|
|
|
/* is no current expedited grace period, */
|
|
|
|
|
/* then there can cannot be any such task. */
|
2011-02-08 04:47:15 +08:00
|
|
|
struct list_head *boost_tasks;
|
|
|
|
|
/* Pointer to first task that needs to be */
|
|
|
|
|
/* priority boosted, or NULL if no priority */
|
|
|
|
|
/* boosting is needed for this rcu_node */
|
|
|
|
|
/* structure. If there are no tasks */
|
|
|
|
|
/* queued on this rcu_node structure that */
|
|
|
|
|
/* are blocking the current grace period, */
|
|
|
|
|
/* there can be no such task. */
|
2014-06-13 04:30:25 +08:00
|
|
|
struct rt_mutex boost_mtx;
|
|
|
|
|
/* Used only for the priority-boosting */
|
|
|
|
|
/* side effect, not as a lock. */
|
2011-02-08 04:47:15 +08:00
|
|
|
unsigned long boost_time;
|
|
|
|
|
/* When to start boosting (jiffies). */
|
|
|
|
|
struct task_struct *boost_kthread_task;
|
|
|
|
|
/* kthread that takes care of priority */
|
|
|
|
|
/* boosting for this rcu_node structure. */
|
2011-03-30 08:48:28 +08:00
|
|
|
unsigned int boost_kthread_status;
|
|
|
|
|
/* State of boost_kthread_task for tracing. */
|
2013-02-11 12:48:58 +08:00
|
|
|
#ifdef CONFIG_RCU_NOCB_CPU
|
2016-02-19 16:46:41 +08:00
|
|
|
struct swait_queue_head nocb_gp_wq[2];
|
2013-02-11 12:48:58 +08:00
|
|
|
/* Place for rcu_nocb_kthread() to wait GP. */
|
|
|
|
|
#endif /* #ifdef CONFIG_RCU_NOCB_CPU */
|
2012-12-31 05:06:35 +08:00
|
|
|
int need_future_gp[2];
|
|
|
|
|
/* Counts of upcoming no-CB GP requests. */
|
2012-06-27 08:00:35 +08:00
|
|
|
raw_spinlock_t fqslock ____cacheline_internodealigned_in_smp;
|
2015-06-25 05:20:08 +08:00
|
|
|
|
2016-01-31 09:57:35 +08:00
|
|
|
spinlock_t exp_lock ____cacheline_internodealigned_in_smp;
|
|
|
|
|
unsigned long exp_seq_rq;
|
2016-03-17 07:47:55 +08:00
|
|
|
wait_queue_head_t exp_wq[4];
|
2009-08-23 04:56:45 +08:00
|
|
|
} ____cacheline_internodealigned_in_smp;
|
|
|
|
|
|
rcu: Correctly handle sparse possible cpus
In many cases in the RCU tree code, we iterate over the set of cpus for
a leaf node described by rcu_node::grplo and rcu_node::grphi, checking
per-cpu data for each cpu in this range. However, if the set of possible
cpus is sparse, some cpus described in this range are not possible, and
thus no per-cpu region will have been allocated (or initialised) for
them by the generic percpu code.
Erroneous accesses to a per-cpu area for these !possible cpus may fault
or may hit other data depending on the addressed generated when the
erroneous per cpu offset is applied. In practice, both cases have been
observed on arm64 hardware (the former being silent, but detectable with
additional patches).
To avoid issues resulting from this, we must iterate over the set of
*possible* cpus for a given leaf node. This patch add a new helper,
for_each_leaf_node_possible_cpu, to enable this. As iteration is often
intertwined with rcu_node local bitmask manipulation, a new
leaf_node_cpu_bit helper is added to make this simpler and more
consistent. The RCU tree code is made to use both of these where
appropriate.
Without this patch, running reboot at a shell can result in an oops
like:
[ 3369.075979] Unable to handle kernel paging request at virtual address ffffff8008b21b4c
[ 3369.083881] pgd = ffffffc3ecdda000
[ 3369.087270] [ffffff8008b21b4c] *pgd=00000083eca48003, *pud=00000083eca48003, *pmd=0000000000000000
[ 3369.096222] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[ 3369.101781] Modules linked in:
[ 3369.104825] CPU: 2 PID: 1817 Comm: NetworkManager Tainted: G W 4.6.0+ #3
[ 3369.121239] task: ffffffc0fa13e000 ti: ffffffc3eb940000 task.ti: ffffffc3eb940000
[ 3369.128708] PC is at sync_rcu_exp_select_cpus+0x188/0x510
[ 3369.134094] LR is at sync_rcu_exp_select_cpus+0x104/0x510
[ 3369.139479] pc : [<ffffff80081109a8>] lr : [<ffffff8008110924>] pstate: 200001c5
[ 3369.146860] sp : ffffffc3eb9435a0
[ 3369.150162] x29: ffffffc3eb9435a0 x28: ffffff8008be4f88
[ 3369.155465] x27: ffffff8008b66c80 x26: ffffffc3eceb2600
[ 3369.160767] x25: 0000000000000001 x24: ffffff8008be4f88
[ 3369.166070] x23: ffffff8008b51c3c x22: ffffff8008b66c80
[ 3369.171371] x21: 0000000000000001 x20: ffffff8008b21b40
[ 3369.176673] x19: ffffff8008b66c80 x18: 0000000000000000
[ 3369.181975] x17: 0000007fa951a010 x16: ffffff80086a30f0
[ 3369.187278] x15: 0000007fa9505590 x14: 0000000000000000
[ 3369.192580] x13: ffffff8008b51000 x12: ffffffc3eb940000
[ 3369.197882] x11: 0000000000000006 x10: ffffff8008b51b78
[ 3369.203184] x9 : 0000000000000001 x8 : ffffff8008be4000
[ 3369.208486] x7 : ffffff8008b21b40 x6 : 0000000000001003
[ 3369.213788] x5 : 0000000000000000 x4 : ffffff8008b27280
[ 3369.219090] x3 : ffffff8008b21b4c x2 : 0000000000000001
[ 3369.224406] x1 : 0000000000000001 x0 : 0000000000000140
...
[ 3369.972257] [<ffffff80081109a8>] sync_rcu_exp_select_cpus+0x188/0x510
[ 3369.978685] [<ffffff80081128b4>] synchronize_rcu_expedited+0x64/0xa8
[ 3369.985026] [<ffffff80086b987c>] synchronize_net+0x24/0x30
[ 3369.990499] [<ffffff80086ddb54>] dev_deactivate_many+0x28c/0x298
[ 3369.996493] [<ffffff80086b6bb8>] __dev_close_many+0x60/0xd0
[ 3370.002052] [<ffffff80086b6d48>] __dev_close+0x28/0x40
[ 3370.007178] [<ffffff80086bf62c>] __dev_change_flags+0x8c/0x158
[ 3370.012999] [<ffffff80086bf718>] dev_change_flags+0x20/0x60
[ 3370.018558] [<ffffff80086cf7f0>] do_setlink+0x288/0x918
[ 3370.023771] [<ffffff80086d0798>] rtnl_newlink+0x398/0x6a8
[ 3370.029158] [<ffffff80086cee84>] rtnetlink_rcv_msg+0xe4/0x220
[ 3370.034891] [<ffffff80086e274c>] netlink_rcv_skb+0xc4/0xf8
[ 3370.040364] [<ffffff80086ced8c>] rtnetlink_rcv+0x2c/0x40
[ 3370.045663] [<ffffff80086e1fe8>] netlink_unicast+0x160/0x238
[ 3370.051309] [<ffffff80086e24b8>] netlink_sendmsg+0x2f0/0x358
[ 3370.056956] [<ffffff80086a0070>] sock_sendmsg+0x18/0x30
[ 3370.062168] [<ffffff80086a21cc>] ___sys_sendmsg+0x26c/0x280
[ 3370.067728] [<ffffff80086a30ac>] __sys_sendmsg+0x44/0x88
[ 3370.073027] [<ffffff80086a3100>] SyS_sendmsg+0x10/0x20
[ 3370.078153] [<ffffff8008085e70>] el0_svc_naked+0x24/0x28
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Dennis Chen <dennis.chen@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2016-06-03 22:20:04 +08:00
|
|
|
/*
|
|
|
|
|
* Bitmasks in an rcu_node cover the interval [grplo, grphi] of CPU IDs, and
|
|
|
|
|
* are indexed relative to this interval rather than the global CPU ID space.
|
|
|
|
|
* This generates the bit for a CPU in node-local masks.
|
|
|
|
|
*/
|
|
|
|
|
#define leaf_node_cpu_bit(rnp, cpu) (1UL << ((cpu) - (rnp)->grplo))
|
|
|
|
|
|
2015-08-07 06:16:57 +08:00
|
|
|
/*
|
|
|
|
|
* Union to allow "aggregate OR" operation on the need for a quiescent
|
|
|
|
|
* state by the normal and expedited grace periods.
|
|
|
|
|
*/
|
|
|
|
|
union rcu_noqs {
|
|
|
|
|
struct {
|
|
|
|
|
u8 norm;
|
|
|
|
|
u8 exp;
|
|
|
|
|
} b; /* Bits. */
|
|
|
|
|
u16 s; /* Set of bits, aggregate OR here. */
|
|
|
|
|
};
|
|
|
|
|
|
2009-08-23 04:56:45 +08:00
|
|
|
/* Per-CPU data for read-copy update. */
|
|
|
|
|
struct rcu_data {
|
|
|
|
|
/* 1) quiescent-state and grace-period handling : */
|
2010-02-23 09:05:01 +08:00
|
|
|
unsigned long completed; /* Track rsp->completed gp number */
|
2009-08-23 04:56:45 +08:00
|
|
|
/* in order to detect GP end. */
|
2010-02-23 09:05:01 +08:00
|
|
|
unsigned long gpnum; /* Highest gp number that this CPU */
|
2009-08-23 04:56:45 +08:00
|
|
|
/* is aware of having started. */
|
rcu: Make cond_resched_rcu_qs() apply to normal RCU flavors
Although cond_resched_rcu_qs() only applies to TASKS_RCU, it is used
in places where it would be useful for it to apply to the normal RCU
flavors, rcu_preempt, rcu_sched, and rcu_bh. This is especially the
case for workloads that aggressively overload the system, particularly
those that generate large numbers of RCU updates on systems running
NO_HZ_FULL CPUs. This commit therefore communicates quiescent states
from cond_resched_rcu_qs() to the normal RCU flavors.
Note that it is unfortunately necessary to leave the old ->passed_quiesce
mechanism in place to allow quiescent states that apply to only one
flavor to be recorded. (Yes, we could decrement ->rcu_qs_ctr_snap in
that case, but that is not so good for debugging of RCU internals.)
In addition, if one of the RCU flavor's grace period has stalled, this
will invoke rcu_momentary_dyntick_idle(), resulting in a heavy-weight
quiescent state visible from other CPUs.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
[ paulmck: Merge commit from Sasha Levin fixing a bug where __this_cpu()
was used in preemptible code. ]
2014-12-14 12:32:04 +08:00
|
|
|
unsigned long rcu_qs_ctr_snap;/* Snapshot of rcu_qs_ctr to check */
|
|
|
|
|
/* for rcu_all_qs() invocations. */
|
2015-08-07 06:16:57 +08:00
|
|
|
union rcu_noqs cpu_no_qs; /* No QSes yet for this CPU. */
|
2015-08-07 02:31:51 +08:00
|
|
|
bool core_needs_qs; /* Core waits for quiesc state. */
|
2009-08-23 04:56:45 +08:00
|
|
|
bool beenonline; /* CPU online at least once. */
|
rcu: Handle gpnum/completed wrap while dyntick idle
Subtle race conditions can result if a CPU stays in dyntick-idle mode
long enough for the ->gpnum and ->completed fields to wrap. For
example, consider the following sequence of events:
o CPU 1 encounters a quiescent state while waiting for grace period
5 to complete, but then enters dyntick-idle mode.
o While CPU 1 is in dyntick-idle mode, the grace-period counters
wrap around so that the grace period number is now 4.
o Just as CPU 1 exits dyntick-idle mode, grace period 4 completes
and grace period 5 begins.
o The quiescent state that CPU 1 passed through during the old
grace period 5 looks like it applies to the new grace period
5. Therefore, the new grace period 5 completes without CPU 1
having passed through a quiescent state.
This could clearly be a fatal surprise to any long-running RCU read-side
critical section that happened to be running on CPU 1 at the time. At one
time, this was not a problem, given that it takes significant time for
the grace-period counters to overflow even on 32-bit systems. However,
with the advent of NO_HZ_FULL and SMP embedded systems, arbitrarily long
idle periods are now becoming quite feasible. It is therefore time to
close this race.
This commit therefore avoids this race condition by having the
quiescent-state forcing code detect when a CPU is falling too far
behind, and setting a new rcu_data field ->gpwrap when this happens.
Whenever this new ->gpwrap field is set, the CPU's ->gpnum and ->completed
fields are known to be untrustworthy, and can be ignored, along with
any associated quiescent states.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2014-12-09 12:26:55 +08:00
|
|
|
bool gpwrap; /* Possible gpnum/completed wrap. */
|
2009-08-23 04:56:45 +08:00
|
|
|
struct rcu_node *mynode; /* This CPU's leaf of hierarchy */
|
|
|
|
|
unsigned long grpmask; /* Mask to apply to leaf qsmask. */
|
2012-01-17 05:29:10 +08:00
|
|
|
unsigned long ticks_this_gp; /* The number of scheduling-clock */
|
|
|
|
|
/* ticks this CPU has handled */
|
|
|
|
|
/* during and after the last grace */
|
|
|
|
|
/* period it is aware of. */
|
2009-08-23 04:56:45 +08:00
|
|
|
|
|
|
|
|
/* 2) batch handling */
|
srcu: Abstract multi-tail callback list handling
RCU has only one multi-tail callback list, which is implemented via
the nxtlist, nxttail, nxtcompleted, qlen_lazy, and qlen fields in the
rcu_data structure, and whose operations are open-code throughout the
Tree RCU implementation. This has been more or less OK in the past,
but upcoming callback-list optimizations in SRCU could really use
a multi-tail callback list there as well.
This commit therefore abstracts the multi-tail callback list handling
into a new kernel/rcu/rcu_segcblist.h file, and uses this new API.
The simple head-and-tail pointer callback list is also abstracted and
applied everywhere except for the NOCB callback-offload lists. (Yes,
the plan is to apply them there as well, but this commit is already
bigger than would be good.)
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2017-02-09 04:36:42 +08:00
|
|
|
struct rcu_segcblist cblist; /* Segmented callback list, with */
|
|
|
|
|
/* different callbacks waiting for */
|
|
|
|
|
/* different grace periods. */
|
2009-10-15 01:15:55 +08:00
|
|
|
long qlen_last_fqs_check;
|
|
|
|
|
/* qlen at last check for QS forcing */
|
|
|
|
|
unsigned long n_force_qs_snap;
|
|
|
|
|
/* did other CPU force QS recently? */
|
2009-08-23 04:56:45 +08:00
|
|
|
long blimit; /* Upper limit on a processed batch */
|
|
|
|
|
|
|
|
|
|
/* 3) dynticks interface. */
|
|
|
|
|
struct rcu_dynticks *dynticks; /* Shared per-CPU dynticks state. */
|
|
|
|
|
int dynticks_snap; /* Per-GP tracking for dynticks. */
|
|
|
|
|
|
|
|
|
|
/* 4) reasons this CPU needed to be kicked by force_quiescent_state */
|
|
|
|
|
unsigned long dynticks_fqs; /* Kicked due to dynticks idle. */
|
|
|
|
|
unsigned long offline_fqs; /* Kicked due to being offline. */
|
2014-06-21 07:49:01 +08:00
|
|
|
unsigned long cond_resched_completed;
|
|
|
|
|
/* Grace period that needs help */
|
|
|
|
|
/* from cond_resched(). */
|
2009-08-23 04:56:45 +08:00
|
|
|
|
2018-01-11 04:36:00 +08:00
|
|
|
/* 5) _rcu_barrier(), OOM callbacks, and expediting. */
|
2012-05-29 14:57:46 +08:00
|
|
|
struct rcu_head barrier_head;
|
2012-06-12 08:39:43 +08:00
|
|
|
#ifdef CONFIG_RCU_FAST_NO_HZ
|
|
|
|
|
struct rcu_head oom_head;
|
|
|
|
|
#endif /* #ifdef CONFIG_RCU_FAST_NO_HZ */
|
2016-06-30 04:46:25 +08:00
|
|
|
atomic_long_t exp_workdone0; /* # done by workqueue. */
|
2016-03-09 06:43:44 +08:00
|
|
|
atomic_long_t exp_workdone1; /* # done by others #1. */
|
|
|
|
|
atomic_long_t exp_workdone2; /* # done by others #2. */
|
|
|
|
|
atomic_long_t exp_workdone3; /* # done by others #3. */
|
2016-10-11 21:09:59 +08:00
|
|
|
int exp_dynticks_snap; /* Double-check need for IPI. */
|
2012-05-29 14:57:46 +08:00
|
|
|
|
2018-01-11 04:36:00 +08:00
|
|
|
/* 6) Callback offloading. */
|
2012-08-20 12:35:53 +08:00
|
|
|
#ifdef CONFIG_RCU_NOCB_CPU
|
|
|
|
|
struct rcu_head *nocb_head; /* CBs waiting for kthread. */
|
|
|
|
|
struct rcu_head **nocb_tail;
|
2014-12-19 04:31:27 +08:00
|
|
|
atomic_long_t nocb_q_count; /* # CBs waiting for nocb */
|
|
|
|
|
atomic_long_t nocb_q_count_lazy; /* invocation (all stages). */
|
rcu: Parallelize and economize NOCB kthread wakeups
An 80-CPU system with a context-switch-heavy workload can require so
many NOCB kthread wakeups that the RCU grace-period kthreads spend several
tens of percent of a CPU just awakening things. This clearly will not
scale well: If you add enough CPUs, the RCU grace-period kthreads would
get behind, increasing grace-period latency.
To avoid this problem, this commit divides the NOCB kthreads into leaders
and followers, where the grace-period kthreads awaken the leaders each of
whom in turn awakens its followers. By default, the number of groups of
kthreads is the square root of the number of CPUs, but this default may
be overridden using the rcutree.rcu_nocb_leader_stride boot parameter.
This reduces the number of wakeups done per grace period by the RCU
grace-period kthread by the square root of the number of CPUs, but of
course by shifting those wakeups to the leaders. In addition, because
the leaders do grace periods on behalf of their respective followers,
the number of wakeups of the followers decreases by up to a factor of two.
Instead of being awakened once when new callbacks arrive and again
at the end of the grace period, the followers are awakened only at
the end of the grace period.
For a numerical example, in a 4096-CPU system, the grace-period kthread
would awaken 64 leaders, each of which would awaken its 63 followers
at the end of the grace period. This compares favorably with the 79
wakeups for the grace-period kthread on an 80-CPU system.
Reported-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2014-06-25 00:26:11 +08:00
|
|
|
struct rcu_head *nocb_follower_head; /* CBs ready to invoke. */
|
|
|
|
|
struct rcu_head **nocb_follower_tail;
|
2016-02-19 16:46:41 +08:00
|
|
|
struct swait_queue_head nocb_wq; /* For nocb kthreads to sleep on. */
|
2012-08-20 12:35:53 +08:00
|
|
|
struct task_struct *nocb_kthread;
|
2017-04-30 11:03:20 +08:00
|
|
|
raw_spinlock_t nocb_lock; /* Guard following pair of fields. */
|
2014-07-30 05:50:47 +08:00
|
|
|
int nocb_defer_wakeup; /* Defer wakeup of nocb_kthread. */
|
2017-04-30 11:03:20 +08:00
|
|
|
struct timer_list nocb_timer; /* Enforce finite deferral. */
|
rcu: Parallelize and economize NOCB kthread wakeups
An 80-CPU system with a context-switch-heavy workload can require so
many NOCB kthread wakeups that the RCU grace-period kthreads spend several
tens of percent of a CPU just awakening things. This clearly will not
scale well: If you add enough CPUs, the RCU grace-period kthreads would
get behind, increasing grace-period latency.
To avoid this problem, this commit divides the NOCB kthreads into leaders
and followers, where the grace-period kthreads awaken the leaders each of
whom in turn awakens its followers. By default, the number of groups of
kthreads is the square root of the number of CPUs, but this default may
be overridden using the rcutree.rcu_nocb_leader_stride boot parameter.
This reduces the number of wakeups done per grace period by the RCU
grace-period kthread by the square root of the number of CPUs, but of
course by shifting those wakeups to the leaders. In addition, because
the leaders do grace periods on behalf of their respective followers,
the number of wakeups of the followers decreases by up to a factor of two.
Instead of being awakened once when new callbacks arrive and again
at the end of the grace period, the followers are awakened only at
the end of the grace period.
For a numerical example, in a 4096-CPU system, the grace-period kthread
would awaken 64 leaders, each of which would awaken its 63 followers
at the end of the grace period. This compares favorably with the 79
wakeups for the grace-period kthread on an 80-CPU system.
Reported-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2014-06-25 00:26:11 +08:00
|
|
|
|
|
|
|
|
/* The following fields are used by the leader, hence own cacheline. */
|
|
|
|
|
struct rcu_head *nocb_gp_head ____cacheline_internodealigned_in_smp;
|
|
|
|
|
/* CBs waiting for GP. */
|
|
|
|
|
struct rcu_head **nocb_gp_tail;
|
2014-08-28 04:43:40 +08:00
|
|
|
bool nocb_leader_sleep; /* Is the nocb leader thread asleep? */
|
rcu: Parallelize and economize NOCB kthread wakeups
An 80-CPU system with a context-switch-heavy workload can require so
many NOCB kthread wakeups that the RCU grace-period kthreads spend several
tens of percent of a CPU just awakening things. This clearly will not
scale well: If you add enough CPUs, the RCU grace-period kthreads would
get behind, increasing grace-period latency.
To avoid this problem, this commit divides the NOCB kthreads into leaders
and followers, where the grace-period kthreads awaken the leaders each of
whom in turn awakens its followers. By default, the number of groups of
kthreads is the square root of the number of CPUs, but this default may
be overridden using the rcutree.rcu_nocb_leader_stride boot parameter.
This reduces the number of wakeups done per grace period by the RCU
grace-period kthread by the square root of the number of CPUs, but of
course by shifting those wakeups to the leaders. In addition, because
the leaders do grace periods on behalf of their respective followers,
the number of wakeups of the followers decreases by up to a factor of two.
Instead of being awakened once when new callbacks arrive and again
at the end of the grace period, the followers are awakened only at
the end of the grace period.
For a numerical example, in a 4096-CPU system, the grace-period kthread
would awaken 64 leaders, each of which would awaken its 63 followers
at the end of the grace period. This compares favorably with the 79
wakeups for the grace-period kthread on an 80-CPU system.
Reported-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2014-06-25 00:26:11 +08:00
|
|
|
struct rcu_data *nocb_next_follower;
|
|
|
|
|
/* Next follower in wakeup chain. */
|
|
|
|
|
|
|
|
|
|
/* The following fields are used by the follower, hence new cachline. */
|
|
|
|
|
struct rcu_data *nocb_leader ____cacheline_internodealigned_in_smp;
|
|
|
|
|
/* Leader CPU takes GP-end wakeups. */
|
2012-08-20 12:35:53 +08:00
|
|
|
#endif /* #ifdef CONFIG_RCU_NOCB_CPU */
|
|
|
|
|
|
2018-01-11 04:36:00 +08:00
|
|
|
/* 7) RCU CPU stall data. */
|
2013-03-07 05:37:09 +08:00
|
|
|
unsigned int softirq_snap; /* Snapshot of softirq activity. */
|
2017-08-18 08:05:59 +08:00
|
|
|
/* ->rcu_iw* fields protected by leaf rcu_node ->lock. */
|
|
|
|
|
struct irq_work rcu_iw; /* Check for non-irq activity. */
|
|
|
|
|
bool rcu_iw_pending; /* Is ->rcu_iw pending? */
|
|
|
|
|
unsigned long rcu_iw_gpnum; /* ->gpnum associated with ->rcu_iw. */
|
2013-03-07 05:37:09 +08:00
|
|
|
|
2009-08-23 04:56:45 +08:00
|
|
|
int cpu;
|
rcu: Add grace-period, quiescent-state, and call_rcu trace events
Add trace events to record grace-period start and end, quiescent states,
CPUs noticing grace-period start and end, grace-period initialization,
call_rcu() invocation, tasks blocking in RCU read-side critical sections,
tasks exiting those same critical sections, force_quiescent_state()
detection of dyntick-idle and offline CPUs, CPUs entering and leaving
dyntick-idle mode (except from NMIs), CPUs coming online and going
offline, and CPUs being kicked for staying in dyntick-idle mode for too
long (as in many weeks, even on 32-bit systems).
Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
rcu: Add the rcu flavor to callback trace events
The earlier trace events for registering RCU callbacks and for invoking
them did not include the RCU flavor (rcu_bh, rcu_preempt, or rcu_sched).
This commit adds the RCU flavor to those trace events.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2011-06-25 21:36:56 +08:00
|
|
|
struct rcu_state *rsp;
|
2009-08-23 04:56:45 +08:00
|
|
|
};
|
|
|
|
|
|
2014-07-30 05:50:47 +08:00
|
|
|
/* Values for nocb_defer_wakeup field in struct rcu_data. */
|
2017-04-29 08:04:09 +08:00
|
|
|
#define RCU_NOCB_WAKE_NOT 0
|
|
|
|
|
#define RCU_NOCB_WAKE 1
|
|
|
|
|
#define RCU_NOCB_WAKE_FORCE 2
|
2014-07-30 05:50:47 +08:00
|
|
|
|
2013-04-04 13:14:11 +08:00
|
|
|
#define RCU_JIFFIES_TILL_FORCE_QS (1 + (HZ > 250) + (HZ > 500))
|
|
|
|
|
/* For jiffies_till_first_fqs and */
|
|
|
|
|
/* and jiffies_till_next_fqs. */
|
2010-03-06 07:03:26 +08:00
|
|
|
|
2013-04-04 13:14:11 +08:00
|
|
|
#define RCU_JIFFIES_FQS_DIV 256 /* Very large systems need more */
|
|
|
|
|
/* delay between bouts of */
|
|
|
|
|
/* quiescent-state forcing. */
|
|
|
|
|
|
|
|
|
|
#define RCU_STALL_RAT_DELAY 2 /* Allow other CPUs time to take */
|
|
|
|
|
/* at least one scheduling clock */
|
|
|
|
|
/* irq before ratting on them. */
|
2009-08-23 04:56:45 +08:00
|
|
|
|
2011-05-21 07:06:29 +08:00
|
|
|
#define rcu_wait(cond) \
|
|
|
|
|
do { \
|
|
|
|
|
for (;;) { \
|
|
|
|
|
set_current_state(TASK_INTERRUPTIBLE); \
|
|
|
|
|
if (cond) \
|
|
|
|
|
break; \
|
|
|
|
|
schedule(); \
|
|
|
|
|
} \
|
|
|
|
|
__set_current_state(TASK_RUNNING); \
|
|
|
|
|
} while (0)
|
2009-08-23 04:56:45 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* RCU global state, including node hierarchy. This hierarchy is
|
|
|
|
|
* represented in "heap" form in a dense array. The root (first level)
|
|
|
|
|
* of the hierarchy is in ->node[0] (referenced by ->level[0]), the second
|
|
|
|
|
* level in ->node[1] through ->node[m] (->node[1] referenced by ->level[1]),
|
|
|
|
|
* and the third level in ->node[m+1] and following (->node[m+1] referenced
|
|
|
|
|
* by ->level[2]). The number of levels is determined by the number of
|
|
|
|
|
* CPUs and by CONFIG_RCU_FANOUT. Small systems will have a "hierarchy"
|
|
|
|
|
* consisting of a single rcu_node.
|
|
|
|
|
*/
|
|
|
|
|
struct rcu_state {
|
|
|
|
|
struct rcu_node node[NUM_RCU_NODES]; /* Hierarchy. */
|
2015-07-09 21:34:23 +08:00
|
|
|
struct rcu_node *level[RCU_NUM_LVLS + 1];
|
|
|
|
|
/* Hierarchy levels (+1 to */
|
|
|
|
|
/* shut bogus gcc warning) */
|
2010-06-28 16:25:04 +08:00
|
|
|
struct rcu_data __percpu *rda; /* pointer of percu rcu_data. */
|
2015-07-29 13:29:39 +08:00
|
|
|
call_rcu_func_t call; /* call_rcu() flavor. */
|
2015-08-01 07:04:45 +08:00
|
|
|
int ncpus; /* # CPUs seen so far. */
|
2009-08-23 04:56:45 +08:00
|
|
|
|
|
|
|
|
/* The following fields are guarded by the root rcu_node's lock. */
|
|
|
|
|
|
2015-09-10 03:09:49 +08:00
|
|
|
u8 boost ____cacheline_internodealigned_in_smp;
|
|
|
|
|
/* Subject to priority boost. */
|
2010-02-23 09:05:01 +08:00
|
|
|
unsigned long gpnum; /* Current gp number. */
|
|
|
|
|
unsigned long completed; /* # of last completed gp. */
|
2012-06-19 09:36:08 +08:00
|
|
|
struct task_struct *gp_kthread; /* Task for grace periods. */
|
2016-02-19 16:46:41 +08:00
|
|
|
struct swait_queue_head gp_wq; /* Where GP task waits. */
|
2014-03-12 22:10:41 +08:00
|
|
|
short gp_flags; /* Commands for GP task. */
|
|
|
|
|
short gp_state; /* GP kthread sleep state. */
|
2009-09-24 00:50:42 +08:00
|
|
|
|
2009-12-03 04:10:15 +08:00
|
|
|
/* End of fields guarded by root rcu_node's lock. */
|
2009-09-24 00:50:42 +08:00
|
|
|
|
2012-05-29 20:18:53 +08:00
|
|
|
struct mutex barrier_mutex; /* Guards barrier fields. */
|
2012-05-29 15:34:56 +08:00
|
|
|
atomic_t barrier_cpu_count; /* # CPUs waiting on. */
|
2012-05-29 18:03:37 +08:00
|
|
|
struct completion barrier_completion; /* Wake at barrier end. */
|
2015-06-27 02:20:00 +08:00
|
|
|
unsigned long barrier_sequence; /* ++ at start and end of */
|
2012-05-30 05:56:46 +08:00
|
|
|
/* _rcu_barrier(). */
|
2012-10-07 23:36:12 +08:00
|
|
|
/* End of fields guarded by barrier_mutex. */
|
|
|
|
|
|
2016-01-31 09:57:35 +08:00
|
|
|
struct mutex exp_mutex; /* Serialize expedited GP. */
|
2016-03-17 07:47:55 +08:00
|
|
|
struct mutex exp_wake_mutex; /* Serialize wakeup. */
|
2015-06-25 01:46:30 +08:00
|
|
|
unsigned long expedited_sequence; /* Take a ticket. */
|
2015-06-26 02:27:10 +08:00
|
|
|
atomic_t expedited_need_qs; /* # CPUs left to check in. */
|
2016-02-19 16:46:41 +08:00
|
|
|
struct swait_queue_head expedited_wq; /* Wait for check-ins. */
|
2015-08-01 07:04:45 +08:00
|
|
|
int ncpus_snap; /* # CPUs seen last time. */
|
2012-10-12 06:24:03 +08:00
|
|
|
|
2009-08-23 04:56:45 +08:00
|
|
|
unsigned long jiffies_force_qs; /* Time at which to invoke */
|
|
|
|
|
/* force_quiescent_state(). */
|
2016-01-04 12:29:57 +08:00
|
|
|
unsigned long jiffies_kick_kthreads; /* Time at which to kick */
|
|
|
|
|
/* kthreads, if configured. */
|
2009-08-23 04:56:45 +08:00
|
|
|
unsigned long n_force_qs; /* Number of calls to */
|
|
|
|
|
/* force_quiescent_state(). */
|
|
|
|
|
unsigned long gp_start; /* Time at which GP started, */
|
|
|
|
|
/* but in jiffies. */
|
2014-12-12 02:20:59 +08:00
|
|
|
unsigned long gp_activity; /* Time of last GP kthread */
|
|
|
|
|
/* activity in jiffies. */
|
2009-08-23 04:56:45 +08:00
|
|
|
unsigned long jiffies_stall; /* Time at which to check */
|
|
|
|
|
/* for CPU stalls. */
|
2013-09-24 04:57:18 +08:00
|
|
|
unsigned long jiffies_resched; /* Time at which to resched */
|
|
|
|
|
/* a reluctant CPU. */
|
2014-12-09 01:57:48 +08:00
|
|
|
unsigned long n_force_qs_gpstart; /* Snapshot of n_force_qs at */
|
|
|
|
|
/* GP start. */
|
2011-04-07 07:01:16 +08:00
|
|
|
unsigned long gp_max; /* Maximum GP duration in */
|
|
|
|
|
/* jiffies. */
|
2013-07-13 04:50:28 +08:00
|
|
|
const char *name; /* Name of structure. */
|
rcu: Distinguish "rcuo" kthreads by RCU flavor
Currently, the per-no-CBs-CPU kthreads are named "rcuo" followed by
the CPU number, for example, "rcuo". This is problematic given that
there are either two or three RCU flavors, each of which gets a per-CPU
kthread with exactly the same name. This commit therefore introduces
a one-letter abbreviation for each RCU flavor, namely 'b' for RCU-bh,
'p' for RCU-preempt, and 's' for RCU-sched. This abbreviation is used
to distinguish the "rcuo" kthreads, for example, for CPU 0 we would have
"rcuob/0", "rcuop/0", and "rcuos/0".
Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
2012-12-04 00:16:28 +08:00
|
|
|
char abbr; /* Abbreviated name. */
|
2012-06-13 02:01:13 +08:00
|
|
|
struct list_head flavors; /* List of RCU flavors. */
|
2009-08-23 04:56:45 +08:00
|
|
|
};
|
|
|
|
|
|
2012-06-23 08:06:26 +08:00
|
|
|
/* Values for rcu_state structure's gp_flags field. */
|
|
|
|
|
#define RCU_GP_FLAG_INIT 0x1 /* Need grace-period initialization. */
|
|
|
|
|
#define RCU_GP_FLAG_FQS 0x2 /* Need grace-period quiescent-state forcing. */
|
|
|
|
|
|
2015-09-11 02:21:28 +08:00
|
|
|
/* Values for rcu_state structure's gp_state field. */
|
2015-09-10 03:09:49 +08:00
|
|
|
#define RCU_GP_IDLE 0 /* Initial state and no GP in progress. */
|
2014-03-12 22:10:41 +08:00
|
|
|
#define RCU_GP_WAIT_GPS 1 /* Wait for grace-period start. */
|
2015-05-20 05:16:52 +08:00
|
|
|
#define RCU_GP_DONE_GPS 2 /* Wait done for grace-period start. */
|
|
|
|
|
#define RCU_GP_WAIT_FQS 3 /* Wait for force-quiescent-state time. */
|
2015-07-03 03:27:31 +08:00
|
|
|
#define RCU_GP_DOING_FQS 4 /* Wait done for force-quiescent-state time. */
|
2015-05-20 05:16:52 +08:00
|
|
|
#define RCU_GP_CLEANUP 5 /* Grace-period cleanup started. */
|
|
|
|
|
#define RCU_GP_CLEANED 6 /* Grace-period cleanup complete. */
|
2014-03-12 22:10:41 +08:00
|
|
|
|
2015-11-18 06:39:26 +08:00
|
|
|
#ifndef RCU_TREE_NONCORE
|
|
|
|
|
static const char * const gp_state_names[] = {
|
|
|
|
|
"RCU_GP_IDLE",
|
|
|
|
|
"RCU_GP_WAIT_GPS",
|
|
|
|
|
"RCU_GP_DONE_GPS",
|
|
|
|
|
"RCU_GP_WAIT_FQS",
|
|
|
|
|
"RCU_GP_DOING_FQS",
|
|
|
|
|
"RCU_GP_CLEANUP",
|
|
|
|
|
"RCU_GP_CLEANED",
|
|
|
|
|
};
|
|
|
|
|
#endif /* #ifndef RCU_TREE_NONCORE */
|
|
|
|
|
|
2012-06-13 02:01:13 +08:00
|
|
|
extern struct list_head rcu_struct_flavors;
|
2012-08-20 12:35:53 +08:00
|
|
|
|
|
|
|
|
/* Sequence through rcu_state structures for each RCU flavor. */
|
2012-06-13 02:01:13 +08:00
|
|
|
#define for_each_rcu_flavor(rsp) \
|
|
|
|
|
list_for_each_entry((rsp), &rcu_struct_flavors, flavors)
|
|
|
|
|
|
2009-03-25 23:42:24 +08:00
|
|
|
/*
|
|
|
|
|
* RCU implementation internal declarations:
|
|
|
|
|
*/
|
2009-08-23 04:56:46 +08:00
|
|
|
extern struct rcu_state rcu_sched_state;
|
2009-03-25 23:42:24 +08:00
|
|
|
|
|
|
|
|
extern struct rcu_state rcu_bh_state;
|
|
|
|
|
|
2014-09-23 02:00:48 +08:00
|
|
|
#ifdef CONFIG_PREEMPT_RCU
|
rcu: Merge preemptable-RCU functionality into hierarchical RCU
Create a kernel/rcutree_plugin.h file that contains definitions
for preemptable RCU (or, under the #else branch of the #ifdef,
empty definitions for the classic non-preemptable semantics).
These definitions fit into plugins defined in kernel/rcutree.c
for this purpose.
This variant of preemptable RCU uses a new algorithm whose
read-side expense is roughly that of classic hierarchical RCU
under CONFIG_PREEMPT. This new algorithm's update-side expense
is similar to that of classic hierarchical RCU, and, in absence
of read-side preemption or blocking, is exactly that of classic
hierarchical RCU. Perhaps more important, this new algorithm
has a much simpler implementation, saving well over 1,000 lines
of code compared to mainline's implementation of preemptable
RCU, which will hopefully be retired in favor of this new
algorithm.
The simplifications are obtained by maintaining per-task
nesting state for running tasks, and using a simple
lock-protected algorithm to handle accounting when tasks block
within RCU read-side critical sections, making use of lessons
learned while creating numerous user-level RCU implementations
over the past 18 months.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: akpm@linux-foundation.org
Cc: mathieu.desnoyers@polymtl.ca
Cc: josht@linux.vnet.ibm.com
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
LKML-Reference: <12509746134003-git-send-email->
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-08-23 04:56:52 +08:00
|
|
|
extern struct rcu_state rcu_preempt_state;
|
2014-09-23 02:00:48 +08:00
|
|
|
#endif /* #ifdef CONFIG_PREEMPT_RCU */
|
rcu: Merge preemptable-RCU functionality into hierarchical RCU
Create a kernel/rcutree_plugin.h file that contains definitions
for preemptable RCU (or, under the #else branch of the #ifdef,
empty definitions for the classic non-preemptable semantics).
These definitions fit into plugins defined in kernel/rcutree.c
for this purpose.
This variant of preemptable RCU uses a new algorithm whose
read-side expense is roughly that of classic hierarchical RCU
under CONFIG_PREEMPT. This new algorithm's update-side expense
is similar to that of classic hierarchical RCU, and, in absence
of read-side preemption or blocking, is exactly that of classic
hierarchical RCU. Perhaps more important, this new algorithm
has a much simpler implementation, saving well over 1,000 lines
of code compared to mainline's implementation of preemptable
RCU, which will hopefully be retired in favor of this new
algorithm.
The simplifications are obtained by maintaining per-task
nesting state for running tasks, and using a simple
lock-protected algorithm to handle accounting when tasks block
within RCU read-side critical sections, making use of lessons
learned while creating numerous user-level RCU implementations
over the past 18 months.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: akpm@linux-foundation.org
Cc: mathieu.desnoyers@polymtl.ca
Cc: josht@linux.vnet.ibm.com
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
LKML-Reference: <12509746134003-git-send-email->
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-08-23 04:56:52 +08:00
|
|
|
|
2016-11-03 08:25:06 +08:00
|
|
|
int rcu_dynticks_snap(struct rcu_dynticks *rdtp);
|
rcu: Maintain special bits at bottom of ->dynticks counter
Currently, IPIs are used to force other CPUs to invalidate their TLBs
in response to a kernel virtual-memory mapping change. This works, but
degrades both battery lifetime (for idle CPUs) and real-time response
(for nohz_full CPUs), and in addition results in unnecessary IPIs due to
the fact that CPUs executing in usermode are unaffected by stale kernel
mappings. It would be better to cause a CPU executing in usermode to
wait until it is entering kernel mode to do the flush, first to avoid
interrupting usemode tasks and second to handle multiple flush requests
with a single flush in the case of a long-running user task.
This commit therefore reserves a bit at the bottom of the ->dynticks
counter, which is checked upon exit from extended quiescent states.
If it is set, it is cleared and then a new rcu_eqs_special_exit() macro is
invoked, which, if not supplied, is an empty single-pass do-while loop.
If this bottom bit is set on -entry- to an extended quiescent state,
then a WARN_ON_ONCE() triggers.
This bottom bit may be set using a new rcu_eqs_special_set() function,
which returns true if the bit was set, or false if the CPU turned
out to not be in an extended quiescent state. Please note that this
function refuses to set the bit for a non-nohz_full CPU when that CPU
is executing in usermode because usermode execution is tracked by RCU
as a dyntick-idle extended quiescent state only for nohz_full CPUs.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
2016-11-09 06:25:21 +08:00
|
|
|
bool rcu_eqs_special_set(int cpu);
|
2016-11-03 08:25:06 +08:00
|
|
|
|
2011-06-21 16:59:33 +08:00
|
|
|
#ifdef CONFIG_RCU_BOOST
|
|
|
|
|
DECLARE_PER_CPU(unsigned int, rcu_cpu_kthread_status);
|
|
|
|
|
DECLARE_PER_CPU(int, rcu_cpu_kthread_cpu);
|
|
|
|
|
DECLARE_PER_CPU(unsigned int, rcu_cpu_kthread_loops);
|
|
|
|
|
DECLARE_PER_CPU(char, rcu_cpu_has_work);
|
|
|
|
|
#endif /* #ifdef CONFIG_RCU_BOOST */
|
|
|
|
|
|
2010-01-15 08:10:58 +08:00
|
|
|
#ifndef RCU_TREE_NONCORE
|
2009-08-23 04:56:45 +08:00
|
|
|
|
2009-09-24 00:50:43 +08:00
|
|
|
/* Forward declarations for rcutree_plugin.h */
|
2009-11-11 05:37:19 +08:00
|
|
|
static void rcu_bootup_announce(void);
|
2017-04-13 06:29:14 +08:00
|
|
|
static void rcu_preempt_note_context_switch(bool preempt);
|
2011-02-08 04:47:15 +08:00
|
|
|
static int rcu_preempt_blocked_readers_cgp(struct rcu_node *rnp);
|
rcu: Fix grace-period-stall bug on large systems with CPU hotplug
When the last CPU of a given leaf rcu_node structure goes
offline, all of the tasks queued on that leaf rcu_node structure
(due to having blocked in their current RCU read-side critical
sections) are requeued onto the root rcu_node structure. This
requeuing is carried out by rcu_preempt_offline_tasks().
However, it is possible that these queued tasks are the only
thing preventing the leaf rcu_node structure from reporting a
quiescent state up the rcu_node hierarchy. Unfortunately, the
old code would fail to do this reporting, resulting in a
grace-period stall given the following sequence of events:
1. Kernel built for more than 32 CPUs on 32-bit systems or for more
than 64 CPUs on 64-bit systems, so that there is more than one
rcu_node structure. (Or CONFIG_RCU_FANOUT is artificially set
to a number smaller than CONFIG_NR_CPUS.)
2. The kernel is built with CONFIG_TREE_PREEMPT_RCU.
3. A task running on a CPU associated with a given leaf rcu_node
structure blocks while in an RCU read-side critical section
-and- that CPU has not yet passed through a quiescent state
for the current RCU grace period. This will cause the task
to be queued on the leaf rcu_node's blocked_tasks[] array, in
particular, on the element of this array corresponding to the
current grace period.
4. Each of the remaining CPUs corresponding to this same leaf rcu_node
structure pass through a quiescent state. However, the task is
still in its RCU read-side critical section, so these quiescent
states cannot be reported further up the rcu_node hierarchy.
Nevertheless, all bits in the leaf rcu_node structure's ->qsmask
field are now zero.
5. Each of the remaining CPUs go offline. (The events in step
#4 and #5 can happen in any order as long as each CPU passes
through a quiescent state before going offline.)
6. When the last CPU goes offline, __rcu_offline_cpu() will invoke
rcu_preempt_offline_tasks(), which will move the task to the
root rcu_node structure, but without reporting a quiescent state
up the rcu_node hierarchy (and this failure to report a quiescent
state is the bug).
But because this leaf rcu_node structure's ->qsmask field is
already zero and its ->block_tasks[] entries are all empty,
force_quiescent_state() will skip this rcu_node structure.
Therefore, grace periods are now hung.
This patch abstracts some code out of rcu_read_unlock_special(),
calling the result task_quiet() by analogy with cpu_quiet(), and
invokes task_quiet() from both rcu_read_lock_special() and
__rcu_offline_cpu(). Invoking task_quiet() from
__rcu_offline_cpu() reports the quiescent state up the rcu_node
hierarchy, fixing the bug. This ends up requiring a separate
lock_class_key per level of the rcu_node hierarchy, which this
patch also provides.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
LKML-Reference: <12589088301770-git-send-email->
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-23 00:53:48 +08:00
|
|
|
#ifdef CONFIG_HOTPLUG_CPU
|
2014-11-01 02:22:37 +08:00
|
|
|
static bool rcu_preempt_has_tasks(struct rcu_node *rnp);
|
rcu: Fix grace-period-stall bug on large systems with CPU hotplug
When the last CPU of a given leaf rcu_node structure goes
offline, all of the tasks queued on that leaf rcu_node structure
(due to having blocked in their current RCU read-side critical
sections) are requeued onto the root rcu_node structure. This
requeuing is carried out by rcu_preempt_offline_tasks().
However, it is possible that these queued tasks are the only
thing preventing the leaf rcu_node structure from reporting a
quiescent state up the rcu_node hierarchy. Unfortunately, the
old code would fail to do this reporting, resulting in a
grace-period stall given the following sequence of events:
1. Kernel built for more than 32 CPUs on 32-bit systems or for more
than 64 CPUs on 64-bit systems, so that there is more than one
rcu_node structure. (Or CONFIG_RCU_FANOUT is artificially set
to a number smaller than CONFIG_NR_CPUS.)
2. The kernel is built with CONFIG_TREE_PREEMPT_RCU.
3. A task running on a CPU associated with a given leaf rcu_node
structure blocks while in an RCU read-side critical section
-and- that CPU has not yet passed through a quiescent state
for the current RCU grace period. This will cause the task
to be queued on the leaf rcu_node's blocked_tasks[] array, in
particular, on the element of this array corresponding to the
current grace period.
4. Each of the remaining CPUs corresponding to this same leaf rcu_node
structure pass through a quiescent state. However, the task is
still in its RCU read-side critical section, so these quiescent
states cannot be reported further up the rcu_node hierarchy.
Nevertheless, all bits in the leaf rcu_node structure's ->qsmask
field are now zero.
5. Each of the remaining CPUs go offline. (The events in step
#4 and #5 can happen in any order as long as each CPU passes
through a quiescent state before going offline.)
6. When the last CPU goes offline, __rcu_offline_cpu() will invoke
rcu_preempt_offline_tasks(), which will move the task to the
root rcu_node structure, but without reporting a quiescent state
up the rcu_node hierarchy (and this failure to report a quiescent
state is the bug).
But because this leaf rcu_node structure's ->qsmask field is
already zero and its ->block_tasks[] entries are all empty,
force_quiescent_state() will skip this rcu_node structure.
Therefore, grace periods are now hung.
This patch abstracts some code out of rcu_read_unlock_special(),
calling the result task_quiet() by analogy with cpu_quiet(), and
invokes task_quiet() from both rcu_read_lock_special() and
__rcu_offline_cpu(). Invoking task_quiet() from
__rcu_offline_cpu() reports the quiescent state up the rcu_node
hierarchy, fixing the bug. This ends up requiring a separate
lock_class_key per level of the rcu_node hierarchy, which this
patch also provides.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: rostedt@goodmis.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
LKML-Reference: <12589088301770-git-send-email->
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-23 00:53:48 +08:00
|
|
|
#endif /* #ifdef CONFIG_HOTPLUG_CPU */
|
2010-02-23 09:05:05 +08:00
|
|
|
static void rcu_print_detail_task_stall(struct rcu_state *rsp);
|
2011-08-14 04:31:47 +08:00
|
|
|
static int rcu_print_task_stall(struct rcu_node *rnp);
|
2015-08-19 01:20:43 +08:00
|
|
|
static int rcu_print_task_exp_stall(struct rcu_node *rnp);
|
2009-09-24 00:50:43 +08:00
|
|
|
static void rcu_preempt_check_blocked_tasks(struct rcu_node *rnp);
|
2014-10-21 23:12:00 +08:00
|
|
|
static void rcu_preempt_check_callbacks(void);
|
2015-07-29 13:29:38 +08:00
|
|
|
void call_rcu(struct rcu_head *head, rcu_callback_t func);
|
2009-09-24 00:50:43 +08:00
|
|
|
static void __init __rcu_init_preempt(void);
|
2011-05-05 12:43:49 +08:00
|
|
|
static void rcu_initiate_boost(struct rcu_node *rnp, unsigned long flags);
|
2011-06-16 06:47:09 +08:00
|
|
|
static void rcu_preempt_boost_start_gp(struct rcu_node *rnp);
|
|
|
|
|
static void invoke_rcu_callbacks_kthread(void);
|
2011-11-30 07:57:13 +08:00
|
|
|
static bool rcu_is_callbacks_kthread(void);
|
2011-06-16 06:47:09 +08:00
|
|
|
#ifdef CONFIG_RCU_BOOST
|
|
|
|
|
static void rcu_preempt_do_callbacks(void);
|
2013-06-20 02:52:21 +08:00
|
|
|
static int rcu_spawn_one_boost_kthread(struct rcu_state *rsp,
|
2012-07-16 18:42:35 +08:00
|
|
|
struct rcu_node *rnp);
|
2011-06-16 06:47:09 +08:00
|
|
|
#endif /* #ifdef CONFIG_RCU_BOOST */
|
2014-07-14 03:00:53 +08:00
|
|
|
static void __init rcu_spawn_boost_kthreads(void);
|
2013-06-20 02:52:21 +08:00
|
|
|
static void rcu_prepare_kthreads(int cpu);
|
2014-10-23 06:07:37 +08:00
|
|
|
static void rcu_cleanup_after_idle(void);
|
2014-10-23 06:03:43 +08:00
|
|
|
static void rcu_prepare_for_idle(void);
|
2012-02-29 03:02:21 +08:00
|
|
|
static void rcu_idle_count_callbacks_posted(void);
|
rcu: Process offlining and onlining only at grace-period start
Races between CPU hotplug and grace periods can be difficult to resolve,
so the ->onoff_mutex is used to exclude the two events. Unfortunately,
this means that it is impossible for an outgoing CPU to perform the
last bits of its offlining from its last pass through the idle loop,
because sleeplocks cannot be acquired in that context.
This commit avoids these problems by buffering online and offline events
in a new ->qsmaskinitnext field in the leaf rcu_node structures. When a
grace period starts, the events accumulated in this mask are applied to
the ->qsmaskinit field, and, if needed, up the rcu_node tree. The special
case of all CPUs corresponding to a given leaf rcu_node structure being
offline while there are still elements in that structure's ->blkd_tasks
list is handled using a new ->wait_blkd_tasks field. In this case,
propagating the offline bits up the tree is deferred until the beginning
of the grace period after all of the tasks have exited their RCU read-side
critical sections and removed themselves from the list, at which point
the ->wait_blkd_tasks flag is cleared. If one of that leaf rcu_node
structure's CPUs comes back online before the list empties, then the
->wait_blkd_tasks flag is simply cleared.
This of course means that RCU's notion of which CPUs are offline can be
out of date. This is OK because RCU need only wait on CPUs that were
online at the time that the grace period started. In addition, RCU's
force-quiescent-state actions will handle the case where a CPU goes
offline after the grace period starts.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
2015-01-24 13:52:37 +08:00
|
|
|
static bool rcu_preempt_has_tasks(struct rcu_node *rnp);
|
2012-01-17 05:29:10 +08:00
|
|
|
static void print_cpu_stall_info_begin(void);
|
|
|
|
|
static void print_cpu_stall_info(struct rcu_state *rsp, int cpu);
|
|
|
|
|
static void print_cpu_stall_info_end(void);
|
|
|
|
|
static void zero_cpu_stall_ticks(struct rcu_data *rdp);
|
|
|
|
|
static void increment_cpu_stall_ticks(void);
|
rcu: Make rcu_barrier() understand about missing rcuo kthreads
Commit 35ce7f29a44a (rcu: Create rcuo kthreads only for onlined CPUs)
avoids creating rcuo kthreads for CPUs that never come online. This
fixes a bug in many instances of firmware: Instead of lying about their
age, these systems instead lie about the number of CPUs that they have.
Before commit 35ce7f29a44a, this could result in huge numbers of useless
rcuo kthreads being created.
It appears that experience indicates that I should have told the
people suffering from this problem to fix their broken firmware, but
I instead produced what turned out to be a partial fix. The missing
piece supplied by this commit makes sure that rcu_barrier() knows not to
post callbacks for no-CBs CPUs that have not yet come online, because
otherwise rcu_barrier() will hang on systems having firmware that lies
about the number of CPUs.
It is tempting to simply have rcu_barrier() refuse to post a callback on
any no-CBs CPU that does not have an rcuo kthread. This unfortunately
does not work because rcu_barrier() is required to wait for all pending
callbacks. It is therefore required to wait even for those callbacks
that cannot possibly be invoked. Even if doing so hangs the system.
Given that posting a callback to a no-CBs CPU that does not yet have an
rcuo kthread can hang rcu_barrier(), It is tempting to report an error
in this case. Unfortunately, this will result in false positives at
boot time, when it is perfectly legal to post callbacks to the boot CPU
before the scheduler has started, in other words, before it is legal
to invoke rcu_barrier().
So this commit instead has rcu_barrier() avoid posting callbacks to
CPUs having neither rcuo kthread nor pending callbacks, and has it
complain bitterly if it finds CPUs having no rcuo kthread but some
pending callbacks. And when rcu_barrier() does find CPUs having no rcuo
kthread but pending callbacks, as noted earlier, it has no choice but
to hang indefinitely.
Reported-by: Yanko Kaneti <yaneti@declera.com>
Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Reported-by: Meelis Roos <mroos@linux.ee>
Reported-by: Eric B Munson <emunson@akamai.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Eric B Munson <emunson@akamai.com>
Tested-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Tested-by: Yanko Kaneti <yaneti@declera.com>
Tested-by: Kevin Fenzi <kevin@scrye.com>
Tested-by: Meelis Roos <mroos@linux.ee>
2014-10-28 00:15:54 +08:00
|
|
|
static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu);
|
2013-02-11 12:48:58 +08:00
|
|
|
static void rcu_nocb_gp_set(struct rcu_node *rnp, int nrq);
|
2016-02-19 16:46:41 +08:00
|
|
|
static struct swait_queue_head *rcu_nocb_gp_get(struct rcu_node *rnp);
|
|
|
|
|
static void rcu_nocb_gp_cleanup(struct swait_queue_head *sq);
|
2013-02-11 12:48:58 +08:00
|
|
|
static void rcu_init_one_nocb(struct rcu_node *rnp);
|
2012-08-20 12:35:53 +08:00
|
|
|
static bool __call_rcu_nocb(struct rcu_data *rdp, struct rcu_head *rhp,
|
rcu: Break call_rcu() deadlock involving scheduler and perf
Dave Jones got the following lockdep splat:
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> 3.12.0-rc3+ #92 Not tainted
> -------------------------------------------------------
> trinity-child2/15191 is trying to acquire lock:
> (&rdp->nocb_wq){......}, at: [<ffffffff8108ff43>] __wake_up+0x23/0x50
>
> but task is already holding lock:
> (&ctx->lock){-.-...}, at: [<ffffffff81154c19>] perf_event_exit_task+0x109/0x230
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (&ctx->lock){-.-...}:
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff81733f90>] _raw_spin_lock+0x40/0x80
> [<ffffffff811500ff>] __perf_event_task_sched_out+0x2df/0x5e0
> [<ffffffff81091b83>] perf_event_task_sched_out+0x93/0xa0
> [<ffffffff81732052>] __schedule+0x1d2/0xa20
> [<ffffffff81732f30>] preempt_schedule_irq+0x50/0xb0
> [<ffffffff817352b6>] retint_kernel+0x26/0x30
> [<ffffffff813eed04>] tty_flip_buffer_push+0x34/0x50
> [<ffffffff813f0504>] pty_write+0x54/0x60
> [<ffffffff813e900d>] n_tty_write+0x32d/0x4e0
> [<ffffffff813e5838>] tty_write+0x158/0x2d0
> [<ffffffff811c4850>] vfs_write+0xc0/0x1f0
> [<ffffffff811c52cc>] SyS_write+0x4c/0xa0
> [<ffffffff8173d4e4>] tracesys+0xdd/0xe2
>
> -> #2 (&rq->lock){-.-.-.}:
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff81733f90>] _raw_spin_lock+0x40/0x80
> [<ffffffff810980b2>] wake_up_new_task+0xc2/0x2e0
> [<ffffffff81054336>] do_fork+0x126/0x460
> [<ffffffff81054696>] kernel_thread+0x26/0x30
> [<ffffffff8171ff93>] rest_init+0x23/0x140
> [<ffffffff81ee1e4b>] start_kernel+0x3f6/0x403
> [<ffffffff81ee1571>] x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81ee1664>] x86_64_start_kernel+0xf1/0xf4
>
> -> #1 (&p->pi_lock){-.-.-.}:
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90
> [<ffffffff810979d1>] try_to_wake_up+0x31/0x350
> [<ffffffff81097d62>] default_wake_function+0x12/0x20
> [<ffffffff81084af8>] autoremove_wake_function+0x18/0x40
> [<ffffffff8108ea38>] __wake_up_common+0x58/0x90
> [<ffffffff8108ff59>] __wake_up+0x39/0x50
> [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0
> [<ffffffff81111450>] __call_rcu+0x140/0x820
> [<ffffffff81111b8d>] call_rcu+0x1d/0x20
> [<ffffffff81093697>] cpu_attach_domain+0x287/0x360
> [<ffffffff81099d7e>] build_sched_domains+0xe5e/0x10a0
> [<ffffffff81efa7fc>] sched_init_smp+0x3b7/0x47a
> [<ffffffff81ee1f4e>] kernel_init_freeable+0xf6/0x202
> [<ffffffff817200be>] kernel_init+0xe/0x190
> [<ffffffff8173d22c>] ret_from_fork+0x7c/0xb0
>
> -> #0 (&rdp->nocb_wq){......}:
> [<ffffffff810cb7ca>] __lock_acquire+0x191a/0x1be0
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90
> [<ffffffff8108ff43>] __wake_up+0x23/0x50
> [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0
> [<ffffffff81111450>] __call_rcu+0x140/0x820
> [<ffffffff81111bb0>] kfree_call_rcu+0x20/0x30
> [<ffffffff81149abf>] put_ctx+0x4f/0x70
> [<ffffffff81154c3e>] perf_event_exit_task+0x12e/0x230
> [<ffffffff81056b8d>] do_exit+0x30d/0xcc0
> [<ffffffff8105893c>] do_group_exit+0x4c/0xc0
> [<ffffffff810589c4>] SyS_exit_group+0x14/0x20
> [<ffffffff8173d4e4>] tracesys+0xdd/0xe2
>
> other info that might help us debug this:
>
> Chain exists of:
> &rdp->nocb_wq --> &rq->lock --> &ctx->lock
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&ctx->lock);
> lock(&rq->lock);
> lock(&ctx->lock);
> lock(&rdp->nocb_wq);
>
> *** DEADLOCK ***
>
> 1 lock held by trinity-child2/15191:
> #0: (&ctx->lock){-.-...}, at: [<ffffffff81154c19>] perf_event_exit_task+0x109/0x230
>
> stack backtrace:
> CPU: 2 PID: 15191 Comm: trinity-child2 Not tainted 3.12.0-rc3+ #92
> ffffffff82565b70 ffff880070c2dbf8 ffffffff8172a363 ffffffff824edf40
> ffff880070c2dc38 ffffffff81726741 ffff880070c2dc90 ffff88022383b1c0
> ffff88022383aac0 0000000000000000 ffff88022383b188 ffff88022383b1c0
> Call Trace:
> [<ffffffff8172a363>] dump_stack+0x4e/0x82
> [<ffffffff81726741>] print_circular_bug+0x200/0x20f
> [<ffffffff810cb7ca>] __lock_acquire+0x191a/0x1be0
> [<ffffffff810c6439>] ? get_lock_stats+0x19/0x60
> [<ffffffff8100b2f4>] ? native_sched_clock+0x24/0x80
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff8108ff43>] ? __wake_up+0x23/0x50
> [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90
> [<ffffffff8108ff43>] ? __wake_up+0x23/0x50
> [<ffffffff8108ff43>] __wake_up+0x23/0x50
> [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0
> [<ffffffff81111450>] __call_rcu+0x140/0x820
> [<ffffffff8109bc8f>] ? local_clock+0x3f/0x50
> [<ffffffff81111bb0>] kfree_call_rcu+0x20/0x30
> [<ffffffff81149abf>] put_ctx+0x4f/0x70
> [<ffffffff81154c3e>] perf_event_exit_task+0x12e/0x230
> [<ffffffff81056b8d>] do_exit+0x30d/0xcc0
> [<ffffffff810c9af5>] ? trace_hardirqs_on_caller+0x115/0x1e0
> [<ffffffff810c9bcd>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff8105893c>] do_group_exit+0x4c/0xc0
> [<ffffffff810589c4>] SyS_exit_group+0x14/0x20
> [<ffffffff8173d4e4>] tracesys+0xdd/0xe2
The underlying problem is that perf is invoking call_rcu() with the
scheduler locks held, but in NOCB mode, call_rcu() will with high
probability invoke the scheduler -- which just might want to use its
locks. The reason that call_rcu() needs to invoke the scheduler is
to wake up the corresponding rcuo callback-offload kthread, which
does the job of starting up a grace period and invoking the callbacks
afterwards.
One solution (championed on a related problem by Lai Jiangshan) is to
simply defer the wakeup to some point where scheduler locks are no longer
held. Since we don't want to unnecessarily incur the cost of such
deferral, the task before us is threefold:
1. Determine when it is likely that a relevant scheduler lock is held.
2. Defer the wakeup in such cases.
3. Ensure that all deferred wakeups eventually happen, preferably
sooner rather than later.
We use irqs_disabled_flags() as a proxy for relevant scheduler locks
being held. This works because the relevant locks are always acquired
with interrupts disabled. We may defer more often than needed, but that
is at least safe.
The wakeup deferral is tracked via a new field in the per-CPU and
per-RCU-flavor rcu_data structure, namely ->nocb_defer_wakeup.
This flag is checked by the RCU core processing. The __rcu_pending()
function now checks this flag, which causes rcu_check_callbacks()
to initiate RCU core processing at each scheduling-clock interrupt
where this flag is set. Of course this is not sufficient because
scheduling-clock interrupts are often turned off (the things we used to
be able to count on!). So the flags are also checked on entry to any
state that RCU considers to be idle, which includes both NO_HZ_IDLE idle
state and NO_HZ_FULL user-mode-execution state.
This approach should allow call_rcu() to be invoked regardless of what
locks you might be holding, the key word being "should".
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
2013-10-05 05:33:34 +08:00
|
|
|
bool lazy, unsigned long flags);
|
2017-06-27 03:23:46 +08:00
|
|
|
static bool rcu_nocb_adopt_orphan_cbs(struct rcu_data *my_rdp,
|
rcu: Break call_rcu() deadlock involving scheduler and perf
Dave Jones got the following lockdep splat:
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> 3.12.0-rc3+ #92 Not tainted
> -------------------------------------------------------
> trinity-child2/15191 is trying to acquire lock:
> (&rdp->nocb_wq){......}, at: [<ffffffff8108ff43>] __wake_up+0x23/0x50
>
> but task is already holding lock:
> (&ctx->lock){-.-...}, at: [<ffffffff81154c19>] perf_event_exit_task+0x109/0x230
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (&ctx->lock){-.-...}:
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff81733f90>] _raw_spin_lock+0x40/0x80
> [<ffffffff811500ff>] __perf_event_task_sched_out+0x2df/0x5e0
> [<ffffffff81091b83>] perf_event_task_sched_out+0x93/0xa0
> [<ffffffff81732052>] __schedule+0x1d2/0xa20
> [<ffffffff81732f30>] preempt_schedule_irq+0x50/0xb0
> [<ffffffff817352b6>] retint_kernel+0x26/0x30
> [<ffffffff813eed04>] tty_flip_buffer_push+0x34/0x50
> [<ffffffff813f0504>] pty_write+0x54/0x60
> [<ffffffff813e900d>] n_tty_write+0x32d/0x4e0
> [<ffffffff813e5838>] tty_write+0x158/0x2d0
> [<ffffffff811c4850>] vfs_write+0xc0/0x1f0
> [<ffffffff811c52cc>] SyS_write+0x4c/0xa0
> [<ffffffff8173d4e4>] tracesys+0xdd/0xe2
>
> -> #2 (&rq->lock){-.-.-.}:
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff81733f90>] _raw_spin_lock+0x40/0x80
> [<ffffffff810980b2>] wake_up_new_task+0xc2/0x2e0
> [<ffffffff81054336>] do_fork+0x126/0x460
> [<ffffffff81054696>] kernel_thread+0x26/0x30
> [<ffffffff8171ff93>] rest_init+0x23/0x140
> [<ffffffff81ee1e4b>] start_kernel+0x3f6/0x403
> [<ffffffff81ee1571>] x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81ee1664>] x86_64_start_kernel+0xf1/0xf4
>
> -> #1 (&p->pi_lock){-.-.-.}:
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90
> [<ffffffff810979d1>] try_to_wake_up+0x31/0x350
> [<ffffffff81097d62>] default_wake_function+0x12/0x20
> [<ffffffff81084af8>] autoremove_wake_function+0x18/0x40
> [<ffffffff8108ea38>] __wake_up_common+0x58/0x90
> [<ffffffff8108ff59>] __wake_up+0x39/0x50
> [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0
> [<ffffffff81111450>] __call_rcu+0x140/0x820
> [<ffffffff81111b8d>] call_rcu+0x1d/0x20
> [<ffffffff81093697>] cpu_attach_domain+0x287/0x360
> [<ffffffff81099d7e>] build_sched_domains+0xe5e/0x10a0
> [<ffffffff81efa7fc>] sched_init_smp+0x3b7/0x47a
> [<ffffffff81ee1f4e>] kernel_init_freeable+0xf6/0x202
> [<ffffffff817200be>] kernel_init+0xe/0x190
> [<ffffffff8173d22c>] ret_from_fork+0x7c/0xb0
>
> -> #0 (&rdp->nocb_wq){......}:
> [<ffffffff810cb7ca>] __lock_acquire+0x191a/0x1be0
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90
> [<ffffffff8108ff43>] __wake_up+0x23/0x50
> [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0
> [<ffffffff81111450>] __call_rcu+0x140/0x820
> [<ffffffff81111bb0>] kfree_call_rcu+0x20/0x30
> [<ffffffff81149abf>] put_ctx+0x4f/0x70
> [<ffffffff81154c3e>] perf_event_exit_task+0x12e/0x230
> [<ffffffff81056b8d>] do_exit+0x30d/0xcc0
> [<ffffffff8105893c>] do_group_exit+0x4c/0xc0
> [<ffffffff810589c4>] SyS_exit_group+0x14/0x20
> [<ffffffff8173d4e4>] tracesys+0xdd/0xe2
>
> other info that might help us debug this:
>
> Chain exists of:
> &rdp->nocb_wq --> &rq->lock --> &ctx->lock
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&ctx->lock);
> lock(&rq->lock);
> lock(&ctx->lock);
> lock(&rdp->nocb_wq);
>
> *** DEADLOCK ***
>
> 1 lock held by trinity-child2/15191:
> #0: (&ctx->lock){-.-...}, at: [<ffffffff81154c19>] perf_event_exit_task+0x109/0x230
>
> stack backtrace:
> CPU: 2 PID: 15191 Comm: trinity-child2 Not tainted 3.12.0-rc3+ #92
> ffffffff82565b70 ffff880070c2dbf8 ffffffff8172a363 ffffffff824edf40
> ffff880070c2dc38 ffffffff81726741 ffff880070c2dc90 ffff88022383b1c0
> ffff88022383aac0 0000000000000000 ffff88022383b188 ffff88022383b1c0
> Call Trace:
> [<ffffffff8172a363>] dump_stack+0x4e/0x82
> [<ffffffff81726741>] print_circular_bug+0x200/0x20f
> [<ffffffff810cb7ca>] __lock_acquire+0x191a/0x1be0
> [<ffffffff810c6439>] ? get_lock_stats+0x19/0x60
> [<ffffffff8100b2f4>] ? native_sched_clock+0x24/0x80
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff8108ff43>] ? __wake_up+0x23/0x50
> [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90
> [<ffffffff8108ff43>] ? __wake_up+0x23/0x50
> [<ffffffff8108ff43>] __wake_up+0x23/0x50
> [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0
> [<ffffffff81111450>] __call_rcu+0x140/0x820
> [<ffffffff8109bc8f>] ? local_clock+0x3f/0x50
> [<ffffffff81111bb0>] kfree_call_rcu+0x20/0x30
> [<ffffffff81149abf>] put_ctx+0x4f/0x70
> [<ffffffff81154c3e>] perf_event_exit_task+0x12e/0x230
> [<ffffffff81056b8d>] do_exit+0x30d/0xcc0
> [<ffffffff810c9af5>] ? trace_hardirqs_on_caller+0x115/0x1e0
> [<ffffffff810c9bcd>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff8105893c>] do_group_exit+0x4c/0xc0
> [<ffffffff810589c4>] SyS_exit_group+0x14/0x20
> [<ffffffff8173d4e4>] tracesys+0xdd/0xe2
The underlying problem is that perf is invoking call_rcu() with the
scheduler locks held, but in NOCB mode, call_rcu() will with high
probability invoke the scheduler -- which just might want to use its
locks. The reason that call_rcu() needs to invoke the scheduler is
to wake up the corresponding rcuo callback-offload kthread, which
does the job of starting up a grace period and invoking the callbacks
afterwards.
One solution (championed on a related problem by Lai Jiangshan) is to
simply defer the wakeup to some point where scheduler locks are no longer
held. Since we don't want to unnecessarily incur the cost of such
deferral, the task before us is threefold:
1. Determine when it is likely that a relevant scheduler lock is held.
2. Defer the wakeup in such cases.
3. Ensure that all deferred wakeups eventually happen, preferably
sooner rather than later.
We use irqs_disabled_flags() as a proxy for relevant scheduler locks
being held. This works because the relevant locks are always acquired
with interrupts disabled. We may defer more often than needed, but that
is at least safe.
The wakeup deferral is tracked via a new field in the per-CPU and
per-RCU-flavor rcu_data structure, namely ->nocb_defer_wakeup.
This flag is checked by the RCU core processing. The __rcu_pending()
function now checks this flag, which causes rcu_check_callbacks()
to initiate RCU core processing at each scheduling-clock interrupt
where this flag is set. Of course this is not sufficient because
scheduling-clock interrupts are often turned off (the things we used to
be able to count on!). So the flags are also checked on entry to any
state that RCU considers to be idle, which includes both NO_HZ_IDLE idle
state and NO_HZ_FULL user-mode-execution state.
This approach should allow call_rcu() to be invoked regardless of what
locks you might be holding, the key word being "should".
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
2013-10-05 05:33:34 +08:00
|
|
|
struct rcu_data *rdp,
|
|
|
|
|
unsigned long flags);
|
2014-07-30 05:50:47 +08:00
|
|
|
static int rcu_nocb_need_deferred_wakeup(struct rcu_data *rdp);
|
rcu: Break call_rcu() deadlock involving scheduler and perf
Dave Jones got the following lockdep splat:
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> 3.12.0-rc3+ #92 Not tainted
> -------------------------------------------------------
> trinity-child2/15191 is trying to acquire lock:
> (&rdp->nocb_wq){......}, at: [<ffffffff8108ff43>] __wake_up+0x23/0x50
>
> but task is already holding lock:
> (&ctx->lock){-.-...}, at: [<ffffffff81154c19>] perf_event_exit_task+0x109/0x230
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #3 (&ctx->lock){-.-...}:
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff81733f90>] _raw_spin_lock+0x40/0x80
> [<ffffffff811500ff>] __perf_event_task_sched_out+0x2df/0x5e0
> [<ffffffff81091b83>] perf_event_task_sched_out+0x93/0xa0
> [<ffffffff81732052>] __schedule+0x1d2/0xa20
> [<ffffffff81732f30>] preempt_schedule_irq+0x50/0xb0
> [<ffffffff817352b6>] retint_kernel+0x26/0x30
> [<ffffffff813eed04>] tty_flip_buffer_push+0x34/0x50
> [<ffffffff813f0504>] pty_write+0x54/0x60
> [<ffffffff813e900d>] n_tty_write+0x32d/0x4e0
> [<ffffffff813e5838>] tty_write+0x158/0x2d0
> [<ffffffff811c4850>] vfs_write+0xc0/0x1f0
> [<ffffffff811c52cc>] SyS_write+0x4c/0xa0
> [<ffffffff8173d4e4>] tracesys+0xdd/0xe2
>
> -> #2 (&rq->lock){-.-.-.}:
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff81733f90>] _raw_spin_lock+0x40/0x80
> [<ffffffff810980b2>] wake_up_new_task+0xc2/0x2e0
> [<ffffffff81054336>] do_fork+0x126/0x460
> [<ffffffff81054696>] kernel_thread+0x26/0x30
> [<ffffffff8171ff93>] rest_init+0x23/0x140
> [<ffffffff81ee1e4b>] start_kernel+0x3f6/0x403
> [<ffffffff81ee1571>] x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81ee1664>] x86_64_start_kernel+0xf1/0xf4
>
> -> #1 (&p->pi_lock){-.-.-.}:
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90
> [<ffffffff810979d1>] try_to_wake_up+0x31/0x350
> [<ffffffff81097d62>] default_wake_function+0x12/0x20
> [<ffffffff81084af8>] autoremove_wake_function+0x18/0x40
> [<ffffffff8108ea38>] __wake_up_common+0x58/0x90
> [<ffffffff8108ff59>] __wake_up+0x39/0x50
> [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0
> [<ffffffff81111450>] __call_rcu+0x140/0x820
> [<ffffffff81111b8d>] call_rcu+0x1d/0x20
> [<ffffffff81093697>] cpu_attach_domain+0x287/0x360
> [<ffffffff81099d7e>] build_sched_domains+0xe5e/0x10a0
> [<ffffffff81efa7fc>] sched_init_smp+0x3b7/0x47a
> [<ffffffff81ee1f4e>] kernel_init_freeable+0xf6/0x202
> [<ffffffff817200be>] kernel_init+0xe/0x190
> [<ffffffff8173d22c>] ret_from_fork+0x7c/0xb0
>
> -> #0 (&rdp->nocb_wq){......}:
> [<ffffffff810cb7ca>] __lock_acquire+0x191a/0x1be0
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90
> [<ffffffff8108ff43>] __wake_up+0x23/0x50
> [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0
> [<ffffffff81111450>] __call_rcu+0x140/0x820
> [<ffffffff81111bb0>] kfree_call_rcu+0x20/0x30
> [<ffffffff81149abf>] put_ctx+0x4f/0x70
> [<ffffffff81154c3e>] perf_event_exit_task+0x12e/0x230
> [<ffffffff81056b8d>] do_exit+0x30d/0xcc0
> [<ffffffff8105893c>] do_group_exit+0x4c/0xc0
> [<ffffffff810589c4>] SyS_exit_group+0x14/0x20
> [<ffffffff8173d4e4>] tracesys+0xdd/0xe2
>
> other info that might help us debug this:
>
> Chain exists of:
> &rdp->nocb_wq --> &rq->lock --> &ctx->lock
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&ctx->lock);
> lock(&rq->lock);
> lock(&ctx->lock);
> lock(&rdp->nocb_wq);
>
> *** DEADLOCK ***
>
> 1 lock held by trinity-child2/15191:
> #0: (&ctx->lock){-.-...}, at: [<ffffffff81154c19>] perf_event_exit_task+0x109/0x230
>
> stack backtrace:
> CPU: 2 PID: 15191 Comm: trinity-child2 Not tainted 3.12.0-rc3+ #92
> ffffffff82565b70 ffff880070c2dbf8 ffffffff8172a363 ffffffff824edf40
> ffff880070c2dc38 ffffffff81726741 ffff880070c2dc90 ffff88022383b1c0
> ffff88022383aac0 0000000000000000 ffff88022383b188 ffff88022383b1c0
> Call Trace:
> [<ffffffff8172a363>] dump_stack+0x4e/0x82
> [<ffffffff81726741>] print_circular_bug+0x200/0x20f
> [<ffffffff810cb7ca>] __lock_acquire+0x191a/0x1be0
> [<ffffffff810c6439>] ? get_lock_stats+0x19/0x60
> [<ffffffff8100b2f4>] ? native_sched_clock+0x24/0x80
> [<ffffffff810cc243>] lock_acquire+0x93/0x200
> [<ffffffff8108ff43>] ? __wake_up+0x23/0x50
> [<ffffffff8173419b>] _raw_spin_lock_irqsave+0x4b/0x90
> [<ffffffff8108ff43>] ? __wake_up+0x23/0x50
> [<ffffffff8108ff43>] __wake_up+0x23/0x50
> [<ffffffff8110d4f8>] __call_rcu_nocb_enqueue+0xa8/0xc0
> [<ffffffff81111450>] __call_rcu+0x140/0x820
> [<ffffffff8109bc8f>] ? local_clock+0x3f/0x50
> [<ffffffff81111bb0>] kfree_call_rcu+0x20/0x30
> [<ffffffff81149abf>] put_ctx+0x4f/0x70
> [<ffffffff81154c3e>] perf_event_exit_task+0x12e/0x230
> [<ffffffff81056b8d>] do_exit+0x30d/0xcc0
> [<ffffffff810c9af5>] ? trace_hardirqs_on_caller+0x115/0x1e0
> [<ffffffff810c9bcd>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff8105893c>] do_group_exit+0x4c/0xc0
> [<ffffffff810589c4>] SyS_exit_group+0x14/0x20
> [<ffffffff8173d4e4>] tracesys+0xdd/0xe2
The underlying problem is that perf is invoking call_rcu() with the
scheduler locks held, but in NOCB mode, call_rcu() will with high
probability invoke the scheduler -- which just might want to use its
locks. The reason that call_rcu() needs to invoke the scheduler is
to wake up the corresponding rcuo callback-offload kthread, which
does the job of starting up a grace period and invoking the callbacks
afterwards.
One solution (championed on a related problem by Lai Jiangshan) is to
simply defer the wakeup to some point where scheduler locks are no longer
held. Since we don't want to unnecessarily incur the cost of such
deferral, the task before us is threefold:
1. Determine when it is likely that a relevant scheduler lock is held.
2. Defer the wakeup in such cases.
3. Ensure that all deferred wakeups eventually happen, preferably
sooner rather than later.
We use irqs_disabled_flags() as a proxy for relevant scheduler locks
being held. This works because the relevant locks are always acquired
with interrupts disabled. We may defer more often than needed, but that
is at least safe.
The wakeup deferral is tracked via a new field in the per-CPU and
per-RCU-flavor rcu_data structure, namely ->nocb_defer_wakeup.
This flag is checked by the RCU core processing. The __rcu_pending()
function now checks this flag, which causes rcu_check_callbacks()
to initiate RCU core processing at each scheduling-clock interrupt
where this flag is set. Of course this is not sufficient because
scheduling-clock interrupts are often turned off (the things we used to
be able to count on!). So the flags are also checked on entry to any
state that RCU considers to be idle, which includes both NO_HZ_IDLE idle
state and NO_HZ_FULL user-mode-execution state.
This approach should allow call_rcu() to be invoked regardless of what
locks you might be holding, the key word being "should".
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
2013-10-05 05:33:34 +08:00
|
|
|
static void do_nocb_deferred_wakeup(struct rcu_data *rdp);
|
2012-08-20 12:35:53 +08:00
|
|
|
static void rcu_boot_init_nocb_percpu_data(struct rcu_data *rdp);
|
2014-07-12 02:30:24 +08:00
|
|
|
static void rcu_spawn_all_nocb_kthreads(int cpu);
|
|
|
|
|
static void __init rcu_spawn_nocb_kthreads(void);
|
|
|
|
|
#ifdef CONFIG_RCU_NOCB_CPU
|
|
|
|
|
static void __init rcu_organize_nocb_kthreads(struct rcu_state *rsp);
|
|
|
|
|
#endif /* #ifdef CONFIG_RCU_NOCB_CPU */
|
2014-06-21 07:49:01 +08:00
|
|
|
static void __maybe_unused rcu_kick_nohz_cpu(int cpu);
|
2013-01-08 05:37:42 +08:00
|
|
|
static bool init_nocb_callback_list(struct rcu_data *rdp);
|
2013-06-22 08:10:40 +08:00
|
|
|
static void rcu_bind_gp_kthread(void);
|
2013-11-09 01:03:10 +08:00
|
|
|
static bool rcu_nohz_full_cpu(struct rcu_state *rsp);
|
2014-08-05 08:43:50 +08:00
|
|
|
static void rcu_dynticks_task_enter(void);
|
|
|
|
|
static void rcu_dynticks_task_exit(void);
|
2009-09-24 00:50:43 +08:00
|
|
|
|
srcu: Parallelize callback handling
Peter Zijlstra proposed using SRCU to reduce mmap_sem contention [1,2],
however, there are workloads that could result in a high volume of
concurrent invocations of call_srcu(), which with current SRCU would
result in excessive lock contention on the srcu_struct structure's
->queue_lock, which protects SRCU's callback lists. This commit therefore
moves SRCU to per-CPU callback lists, thus greatly reducing contention.
Because a given SRCU instance no longer has a single centralized callback
list, starting grace periods and invoking callbacks are both more complex
than in the single-list Classic SRCU implementation. Starting grace
periods and handling callbacks are now handled using an srcu_node tree
that is in some ways similar to the rcu_node trees used by RCU-bh,
RCU-preempt, and RCU-sched (for example, the srcu_node tree shape is
controlled by exactly the same Kconfig options and boot parameters that
control the shape of the rcu_node tree).
In addition, the old per-CPU srcu_array structure is now named srcu_data
and contains an rcu_segcblist structure named ->srcu_cblist for its
callbacks (and a spinlock to protect this). The srcu_struct gets
an srcu_gp_seq that is used to associate callback segments with the
corresponding completion-time grace-period number. These completion-time
grace-period numbers are propagated up the srcu_node tree so that the
grace-period workqueue handler can determine whether additional grace
periods are needed on the one hand and where to look for callbacks that
are ready to be invoked.
The srcu_barrier() function must now wait on all instances of the per-CPU
->srcu_cblist. Because each ->srcu_cblist is protected by ->lock,
srcu_barrier() can remotely add the needed callbacks. In theory,
it could also remotely start grace periods, but in practice doing so
is complex and racy. And interestingly enough, it is never necessary
for srcu_barrier() to start a grace period because srcu_barrier() only
enqueues a callback when a callback is already present--and it turns out
that a grace period has to have already been started for this pre-existing
callback. Furthermore, it is only the callback that srcu_barrier()
needs to wait on, not any particular grace period. Therefore, a new
rcu_segcblist_entrain() function enqueues the srcu_barrier() function's
callback into the same segment occupied by the last pre-existing callback
in the list. The special case where all the pre-existing callbacks are
on a different list (because they are in the process of being invoked)
is handled by enqueuing srcu_barrier()'s callback into the RCU_DONE_TAIL
segment, relying on the done-callbacks check that takes place after all
callbacks are inovked.
Note that the readers use the same algorithm as before. Note that there
is a separate srcu_idx that tells the readers what counter to increment.
This unfortunately cannot be combined with srcu_gp_seq because they
need to be incremented at different times.
This commit introduces some ugly #ifdefs in rcutorture. These will go
away when I feel good enough about Tree SRCU to ditch Classic SRCU.
Some crude performance comparisons, courtesy of a quickly hacked rcuperf
asynchronous-grace-period capability:
Callback Queuing Overhead
-------------------------
# CPUS Classic SRCU Tree SRCU
------ ------------ ---------
2 0.349 us 0.342 us
16 31.66 us 0.4 us
41 --------- 0.417 us
The times are the 90th percentiles, a statistic that was chosen to reject
the overheads of the occasional srcu_barrier() call needed to avoid OOMing
the test machine. The rcuperf test hangs when running Classic SRCU at 41
CPUs, hence the line of dashes. Despite the hacks to both the rcuperf code
and that statistics, this is a convincing demonstration of Tree SRCU's
performance and scalability advantages.
[1] https://lwn.net/Articles/309030/
[2] https://patchwork.kernel.org/patch/5108281/
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
[ paulmck: Fix initialization if synchronize_srcu_expedited() called first. ]
2017-04-06 00:01:53 +08:00
|
|
|
#ifdef CONFIG_SRCU
|
|
|
|
|
void srcu_online_cpu(unsigned int cpu);
|
|
|
|
|
void srcu_offline_cpu(unsigned int cpu);
|
|
|
|
|
#else /* #ifdef CONFIG_SRCU */
|
|
|
|
|
void srcu_online_cpu(unsigned int cpu) { }
|
|
|
|
|
void srcu_offline_cpu(unsigned int cpu) { }
|
|
|
|
|
#endif /* #else #ifdef CONFIG_SRCU */
|
|
|
|
|
|
2010-01-15 08:10:58 +08:00
|
|
|
#endif /* #ifndef RCU_TREE_NONCORE */
|