Re: Linux 3.19-rc3

[Peter Zijlstra]

On Tue, Jan 06, 2015 at 03:56:45AM -0800, Kent Overstreet wrote:
> I do want to make the point that it's not really the callers that are broken;
> especially those that are using prepare_to_wait() via wait_event(). Using
> wait_event() is exactly what people _should_ be doing, instead of open coding
> this stuff and/or coming up with hacks to work around the fact that
> prepare_to_wait() is implemented via messing with the task state.

Yes and no.

So I agree that people should be using wait_event(), but I was also very
much hoping people would not be nesting sleep primitives like this.

Now that we have the debug check its at least obvious when you do.

But yes I'm somewhat saddened by the amount of stuff that has come up
because of this.

> Anyways, my point is either wait_event() should be fixed to not muck with the
> task state, or since that's not really practical we should at least provide a
> standard drop in replacement that doesn't.

I had explicitly not done this because I had hoped this would be rare
and feel/felt we should not encourage this pattern.

> And the drop in replacement more or less exists, closure_wait_event() has the
> same semantics as wait_event, similarly with the lower level primitives I just
> listed the conversions for.

See my other email, I don't really agree with the whole
closure_wait_event() thing, I think it dilutes what closures are. You've
just used what you know to cobble together something that has the right
semantics, but its not at all related to the concept of what closures
were.

I'm also not sure we want to change the existing wait_event() stuff to
allow nested sleeps per default, there is some additional overhead
involved -- although it could turn out to not be an issue, we'd have to
look at that.

But IF we want to create a drop in replacement it should be in the wait
code, it shouldn't be too hard once we've decided we do indeed want to
go do this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/