On Sun, Mar 16, 2014 at 07:14:15AM +0100, Mike Galbraith wrote: > On Sun, 2014-03-16 at 07:09 +0100, Mike Galbraith wrote: > > On Sat, 2014-03-15 at 18:59 -0700, Paul E. McKenney wrote: > > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > > index b46131ef6aab..994d2b0fd0b2 100644 > > > --- a/kernel/sched/core.c > > > +++ b/kernel/sched/core.c > > > @@ -4075,6 +4075,9 @@ int __sched _cond_resched(void) > > > __cond_resched(); > > > return 1; > > > } > > > + preempt_disable(); > > > + rcu_note_context_switch(smp_processor_id()); > > > + preempt_enable(); > > > return 0; > > > } > > > EXPORT_SYMBOL(_cond_resched); > > > > Hm. Since you only care about the case where your task is solo, how > > about do racy checks, 100% accuracy isn't required is it? Seems you > > wouldn't want to unconditionally do that in tight loops. > > (or do that in scheduler_tick()?)
There are checks in scheduler_tick(), but they have to assume that if they interrupt kernel execution, they might have also interrupted an RCU read-side critical section. And in fact, the point of having cond_resched() (sometimes) do a quiescent state is to communicate with the existing checks invoked from scheduler_tick(). Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/