Re: [PATCH 1/2] rcu: Explain why rcu_all_qs() is a stub in preemptible TREE RCU

[Paul E. McKenney]

On Tue, Jul 06, 2021 at 01:43:43AM +0200, Frederic Weisbecker wrote:
> 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@xxxxxxxxxx>
> Cc: Neeraj Upadhyay <neeraju@xxxxxxxxxxxxxx>
> Cc: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
> Cc: Uladzislau Rezki <urezki@xxxxxxxxx>
> Cc: Boqun Feng <boqun.feng@xxxxxxxxx>
> Cc: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> ---
>  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

Looks like a good addition!  I have wordsmithed the comment and
commit log a bit.  If Peter wants to take either version of this:

Acked-by: Paul E. McKenney <paulmck@xxxxxxxxxx>

In the meantime, I have queued it for v5.15.

							Thanx, Paul

------------------------------------------------------------------------

commit 41a95363ac9f020cc0e4fcc4b73015c60b6620f0
Author: Frederic Weisbecker <frederic@xxxxxxxxxx>
Date:   Tue Jul 6 01:43:43 2021 +0200

    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: Frederic Weisbecker <frederic@xxxxxxxxxx>
    Cc: Neeraj Upadhyay <neeraju@xxxxxxxxxxxxxx>
    Cc: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
    Cc: Uladzislau Rezki <urezki@xxxxxxxxx>
    Cc: Boqun Feng <boqun.feng@xxxxxxxxx>
    Cc: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
    Cc: Ingo Molnar <mingo@xxxxxxxxxx>
    Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index cf16f8fda9a6..eae24fdf3820 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7780,6 +7780,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