On Tue, Aug 08, 2017 at 10:50:26PM +0530, Neeraj Upadhyay wrote:For boot time configuration, agree, there isn't much point in enabling
If rcu_kick_kthreads is set, and gp is in progress, check_cpu_stall()Just to make sure I understand, the concern is that someone might have
does checks to figure out whether jiffies is past rsp->jiffies_stall,
doing ordered accesses to avoid any false positives for new grace
period initialization after a sufficiently large idle period. This
extra processing can be skipped if rcu_cpu_stall_suppress is set.
booted with rcupdate.rcu_cpu_stall_suppress=1 (thus suppressing the RCU
CPU stall debugging warnings implemented later in check_cpu_stall()),
but later decided to also boot with rcutree.rcu_kick_kthreads=1 (thus
enabling kicking kthreads which check for RCU's grace-period kthreads
not being properly awakened)?
My immediate reaction is that if there is not much point in specifying
both rcutree.rcu_kick_kthreads=1 and rcupdate.rcu_cpu_stall_suppress=1.
But is there some use case that I am missing?
Thanx, Paul
Fixes: 8c7c4829a81c ("rcu: Awaken grace-period kthread if too long since FQS")
Signed-off-by: Neeraj Upadhyay <neeraju@xxxxxxxxxxxxxx>
---
kernel/rcu/tree.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 51d4c3a..91b7552 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1562,10 +1562,13 @@ static void check_cpu_stall(struct rcu_state *rsp, struct rcu_data *rdp)
unsigned long js;
struct rcu_node *rnp;
- if ((rcu_cpu_stall_suppress && !rcu_kick_kthreads) ||
- !rcu_gp_in_progress(rsp))
+ if (!rcu_gp_in_progress(rsp))
return;
rcu_stall_kick_kthreads(rsp);
+
+ if (rcu_cpu_stall_suppress)
+ return;
+
j = jiffies;
/*
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation