sched: update __cond_resched comment about RCU quiescent states

Update comment in __cond_resched() clarifying how urgently needed
quiescent state are provided.

Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 165c90ba64ea93b65e4db83f7b0d411553e4fdc0..d328707626e30a1a9bce0ca72b608ad73ab7b710 100644 (file)
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7289,7 +7289,7 @@ int __sched __cond_resched(void)
                return 1;
        }
        /*
-        * In preemptible kernels, ->rcu_read_lock_nesting tells the tick
+        * In PREEMPT_RCU kernels, ->rcu_read_lock_nesting tells the tick
         * whether the current CPU is in an RCU read-side critical section,
         * so the tick can report quiescent states even for CPUs looping
         * in kernel context.  In contrast, in non-preemptible kernels,
@@ -7298,6 +7298,8 @@ int __sched __cond_resched(void)
         * RCU quiescent state.  Therefore, the following code causes
         * cond_resched() to report a quiescent state, but only when RCU
         * is in urgent need of one.
+        * A third case, preemptible, but non-PREEMPT_RCU provides for
+        * urgently needed quiescent states via rcu_flavor_sched_clock_irq().
         */
 #ifndef CONFIG_PREEMPT_RCU
        rcu_all_qs();