lkml.org 
[lkml]   [2017]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH tip/core/rcu 11/20] sched,rcu: Make cond_resched() provide RCU quiescent state
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.


\
 
 \ /
  Last update: 2017-01-16 18:12    [W:0.305 / U:1.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site