diff options
| author |   Paul E. McKenney <paulmck@linux.ibm.com> | 2018-11-20 10:43:34 -0800 |
|---|---|---|
| committer | Paul E. McKenney <paulmck@linux.ibm.com> | 2019-01-25 15:29:53 -0800 |
| commit | 9cf422a8e71455032b61c6c0ea56a1e96206aab0 (patch) | |
| tree | 78a31267b797687ffb383d2e9de879874f3bdc3c /kernel | |
| parent | tools/memory-model: Make scripts take "-j" abbreviation for "--jobs" (diff) | |
| download | linux-dev-9cf422a8e71455032b61c6c0ea56a1e96206aab0.tar.xz linux-dev-9cf422a8e71455032b61c6c0ea56a1e96206aab0.zip | |
rcu: Accommodate zero jiffies_till_first_fqs and kthread kicking
It is perfectly fine to set the rcutree.jiffies_till_first_fqs boot
parameter to zero, in fact, this can be useful on specialty systems that
usually have at least one idle CPU and that need fast grace periods.
This is because this setting causes the RCU grace-period kthread to
scan for idle threads immediately after grace-period initialization,
as opposed to waiting several jiffies to do so.
It is also perfectly fine to set the rcutree.rcu_kick_kthreads kernel
parameter, which gives the RCU grace-period kthread an extra wakeup
if it doesn't make progress for a period of three times the setting of
the rcutree.jiffies_till_first_fqs boot parameter. This is of course
problematic when the value of this parameter is zero, as it can result
in unnecessary wakeup IPIs along with unnecessary WARN_ONCE() invocations.
This commit therefore defers kthread kicking for at least two jiffies,
regardless of the setting of rcutree.jiffies_till_first_fqs.
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Diffstat (limited to 'kernel')
| -rw-r--r-- | kernel/rcu/tree.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 9180158756d2..b003a3cfe192 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1939,7 +1939,7 @@ static void rcu_gp_fqs_loop(void) if (!ret) { rcu_state.jiffies_force_qs = jiffies + j; WRITE_ONCE(rcu_state.jiffies_kick_kthreads, - jiffies + 3 * j); + jiffies + (j ? 3 * j : 2)); } trace_rcu_grace_period(rcu_state.name, READ_ONCE(rcu_state.gp_seq), |