[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141031214836.GQ10501@worktop.programming.kicks-ass.net>
Date: Fri, 31 Oct 2014 22:48:36 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: mingo@...nel.org, linux-kernel@...r.kernel.org,
peter@...leysoftware.com, rjw@...ysocki.net,
torvalds@...ux-foundation.org, tglx@...utronix.de,
eparis@...hat.com, umgwanakikbuti@...il.com, marcel@...tmann.org,
ebiederm@...ssion.com, davem@...emloft.net, fengguang.wu@...el.com
Subject: Re: [PATCH 2/7] wait: Reimplement wait_event_freezable()
On Fri, Oct 31, 2014 at 10:38:02PM +0100, Oleg Nesterov wrote:
> On 10/31, Peter Zijlstra wrote:
> >
> > Provide better implementations of wait_event_freezable() APIs.
> >
> > The problem is with freezer_do_not_count(), it hides the thread from
> > the freezer, even though this thread might not actually freeze/sleep
> > at all.
>
> I agree, wait_event_freezable() is awful. But could you clarify "at all" ?
>
> Sure, the task can be preempted right after it sets, it can do a lot
> of things before it calls schedule(), it can be woken after that and
> it can run again and do something else before freezer_count() calls
> try_to_freeze(), etc.
>
> Is this what you meant?
Yes.
> > +#define __wait_event_freezable(wq, condition) \
> > + (void)___wait_event(wq, condition, TASK_INTERRUPTIBLE, 0, 0, \
> > + schedule(); try_to_freeze())
>
> I don't think this can work.
Yeah, that was horribly broken. defconfig didn't seem to find a usage
site. Wu's robot offered a .config quickly enough though ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists