Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1234220 > unrolled thread

Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug() Peter Zijlstra <peterz@infradead.org> - 2015-09-28 16:50 +0200
    Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug() Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-28 18:10 +0200
      Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug() Ingo Molnar <mingo@kernel.org> - 2015-09-29 10:00 +0200

#1234220 — Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()

On Fri, Sep 18, 2015 at 09:12:38AM -0700, Linus Torvalds wrote:
> 
> So I disagree with your notion that it's a recursion flag. It is
> absolutely nothing of the sort.

OK, agreed. I had it classed under recursion in my head, clearly I
indexed it sloppily. In any case I have a patch that kills off
PREEMPT_ACTIVE entirely.

I just have to clean it up, benchmark, split and write changelogs. But
it should be forthcoming 'soon'. As is, it boots..

> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1234269

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.

            Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1234789

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web