Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 11 May 2018 12:23:21 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri, 11 May 2018 09:17:46 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> > > >index ee8cf5fc..7432261 100644
> > > >--- a/include/linux/rcupdate.h
> > > >+++ b/include/linux/rcupdate.h
> > > >@@ -195,8 +195,8 @@ static inline void exit_tasks_rcu_finish(void) { }
> > > >   */
> > > >  #define cond_resched_tasks_rcu_qs() \
> > > >  do { \
> > > >-	if (!cond_resched()) \
> > > >-		rcu_note_voluntary_context_switch_lite(current); \
> > > >+	rcu_note_voluntary_context_switch_lite(current); \
> > > >+	cond_resched(); \    
> > 
> > Ah, good point.
> > 
> > Peter, I have to ask...  Why is "cond_resched()" considered a preemption
> > while "schedule()" is not?  
> 
> I would argue that cond_resched() not be considered a preemption.
> Although, it may be called a "preemption point". A place that can be
> preempted, but may not be. Maybe that's the answer. schedule() will
> always schedule (even though it may pick the same task to run, but
> not guaranteed to), where as, cond_resched() will only schedule if the
> conditions are right. And maybe that's not really a "voluntary
> schedule", although I think that can be argued against.
> 

I would also say that one should never call schedule() directly without
changing its state to something other than TASK_RUNNING. Hence, calling
schedule directly is saying you are ready to sleep. But that is not the
case with cond_resched() which should always be called with the state
as TASK_RUNNING.

-- Steve