Messages in this thread Patch in this message | | | From | Frederic Weisbecker <> | Subject | [PATCH 1/2] rcu: Explain why rcu_all_qs() is a stub in preemptible TREE RCU | Date | Tue, 6 Jul 2021 01:43:43 +0200 |
| |
cond_resched() reports an RCU quiescent state only in non-preemptible TREE RCU implementation. Provide an explanation for the different behaviour in CONFIG_PREEMPT_RCU=y.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Cc: Neeraj Upadhyay <neeraju@codeaurora.org> Cc: Joel Fernandes <joel@joelfernandes.org> Cc: Uladzislau Rezki <urezki@gmail.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> --- kernel/sched/core.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index cf16f8fda9a6..db374cb38eb2 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -7780,6 +7780,19 @@ int __sched __cond_resched(void) preempt_schedule_common(); return 1; } + /* + * A process spending a long time in the kernel space might + * have too few opportunities to report quiescent states + * when CONFIG_PREEMPT_RCU=n because then the tick can't know + * if it's interrupting an RCU read side critical section. In the + * absence of voluntary sleeps, the last resort resides in tracking + * calls to cond_resched() which always imply quiescent states. + * + * On the other hand, preemptible RCU has a real RCU read side + * tracking that allows the tick for reporting interrupted quiescent + * states or, in the worst case, deferred quiescent states after + * rcu_read_unlock(). + */ #ifndef CONFIG_PREEMPT_RCU rcu_all_qs(); #endif -- 2.25.1
| |