lkml.org 
[lkml]   [2007]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/3] make kthread_stop() scalable
    On 04/14, Eric W. Biederman wrote:
    >
    > This is where I was going beyond what you were doing. I needed a flag to say
    > that this a kthread that is stopping to test in recalc_sigpending. To be certain
    > of terminating interruptible sleeps. I could not get at your struct kthread
    > in that case.
    >
    > If it wasn't for the wait_event_interruptible thing I likely would
    > have just thrown a union in struct task_struct.
    >
    > I also got lucky in that vfork_done is designed to point a completion
    > just where I need it (when a task exits). The name is now a little
    > abused but otherwise it does just what I want it to.
    >
    > >> It also doesn't solve the biggest problem with the current kthread interface
    > >> in that calling kthread_stop does not cause the code to break out of
    > >> interruptible sleeps.
    > >
    > > Hm? kthread_stop() does wake_up_process(), it wakes up TASK_INTERRUPTIBLE tasks.
    >
    > Yes. But if they are looping, unless signal_pending is set it is quite possible
    > they will go back to sleep.
    >
    > Take for example:
    >
    > > #define __wait_event_interruptible(wq, condition, ret) \
    > > do { \
    > > DEFINE_WAIT(__wait); \
    > > \
    > > for (;;) { \
    > > prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE); \
    > > if (condition) \
    > > break; \
    > > if (!signal_pending(current)) { \
    > > schedule(); \
    > > continue; \
    > > } \
    > > ret = -ERESTARTSYS; \
    > > break; \
    > > } \
    > > finish_wait(&wq, &__wait); \
    > > } while (0)
    >
    > We don't break out until either condition is true or signal_pending(current)
    > is true.
    >
    > Loops that do that are very common in the kernel. I counted about 500
    > calls of signal pending in places that otherwise care nothing about signals.
    > Several kernel threads call into functions that use loops like
    > wait_event_interruptible. So I need a more forceful kthread_stop. If
    > I don't want to continue to use signals.

    Yes, I got it reading your next patches. Ok, probably this change is good.
    My question was: do we really want to force a kernel thread to exit if it
    waits for event in TASK_INTERRUPTIBLE state? probably yes.

    > > Yes, thanks... Can't understand how I was soooo stupid!!! thanks...
    > >
    > > Damn. We don't need 2 completions! just one.
    >
    > Yep. My second patch in this last round implements that.

    Yes, I have read it. It is clearly better then mine, and I think correct.

    Oleg.

    -
    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/

    \
     
     \ /
      Last update: 2007-04-14 20:53    [W:3.636 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site