lkml.org 
[lkml]   [2015]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Sep 28, 2015 at 10:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> >> It gets set by preemption - and,
> >> somewhat illogically, by cond_resched().
> >
> > I suspect that was done to make cond_resched() (voluntary preemption)
> > more robust and only have a single preemption path/logic. But all that
> > was done well before I got involved.
>
> So I think it's actually the name that is bad, not necessarily the behavior.
>
> We tend to put "cond_resched()" (and particularly
> "cond_resched_lock()") in some fairly awkward places, and it's not
> always entirely clear that task->state == TASK_RUNNING there.
>
> So the preemptive behavior of not *really* putting the task to sleep
> may actually be the right one. But it is rather non-intuitive given
> the name - because "cond_resched()" basically is not at all equivalent
> to "if (need_resched()) schedule()", which you'd kind of expect.
>
> An explicit schedule will actually act on the task->state, and make us
> go to sleep. "cond_resched()" really is just a "voluntary preemption
> point". And I think it would be better if it got named that way.

cond_preempt() perhaps? That would allude to preempt_schedule() and such, and
would make it clearer that it's supposed to be an invariant on the sleep state
(which schedule() is not).

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-09-29 10:01    [W:0.362 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site