lkml.org 
[lkml]   [2018]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] rcu: Report a quiescent state when it's exactly in the state
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

\
 
 \ /
  Last update: 2018-05-11 18:26    [W:0.087 / U:19.768 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site