Re: [PATCH tip/core/rcu 11/20] sched,rcu: Make cond_resched() provide RCU quiescent state

[Peter Zijlstra <peterz@infradead.org>]

On Sat, Jan 14, 2017 at 01:13:12AM -0800, Paul E. McKenney wrote:
> There is some confusion as to which of cond_resched() or
> cond_resched_rcu_qs() should be added to long in-kernel loops.
> This commit therefore eliminates the decision by adding RCU
> quiescent states to cond_resched().

Which would make: rcu_read_lock(); cond_resched(); rcu_read_unlock();
invalid under preemptible RCU. Is it already?

> Warning: This is a prototype.  For example, it does not correctly
> handle Tasks RCU.  Which is OK for the moment, given that no one
> actually uses Tasks RCU yet.

> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4907,6 +4907,7 @@ int __sched _cond_resched(void)
>  		preempt_schedule_common();
>  		return 1;
>  	}
> +	rcu_all_qs();
>  	return 0;
>  }

Still not a real fan of this, it does make cond_resched() touch a bunch
more cachelines, also, I suppose that if we're going to do this, we
should make __cond_resched_lock() and __cond_resched_softirq() act
similarly.