Commit 50895825 authored by Frederic Weisbecker's avatar Frederic Weisbecker Committed by Paul E. McKenney
Browse files

rcu: Explain why rcu_all_qs() is a stub in preemptible TREE RCU 



The cond_resched() function reports an RCU quiescent state only in
non-preemptible TREE RCU implementation.  This commit therefore adds a
comment explaining why cond_resched() does nothing in preemptible kernels.

Signed-off-by: default avatarFrederic 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>
Signed-off-by: default avatarPaul E. McKenney <paulmck@kernel.org>
parent 8211e922

kernel/sched/core.c

+11 −0
Original line number Diff line number Diff line
@@ -7781,6 +7781,17 @@ int __sched __cond_resched(void) 
		preempt_schedule_common();

		return 1;

	}

	/*

	 * In preemptible 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,

	 * RCU readers leave no in-memory hints, which means that CPU-bound

	 * processes executing in kernel context might never report an

	 * 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.

	 */

#ifndef CONFIG_PREEMPT_RCU

	rcu_all_qs();

#endif