Hello,

On Tue, 12 May 2015, Peter Zijlstra wrote:

> >     msleep will not return until timeout has expired.
> > Instead, we want to notice the kthread_should_stop() event
> > immediately. Additionally, TASK_UNINTERRUPTIBLE will increase
> > the load average. We can do it with extra wait queue
> > and the new __wait_event_idle_timeout but I guess
> > schedule_timeout_idle will be a good replacement for
> > schedule_timeout_interruptible calls when used for kthreads.
> 
> Fair enough I suppose, but then calling it schedule*() is just plain
> wrong, it does not behave/act like a normal schedule() call.
> 
> Lemme go look at how widely abused that is.
> 
> *sigh*, its all over the place :/
> 
> $ git grep "schedule_timeout_\(interruptible\|killable\|uninterruptible\)" | 
> wc -l
> 392
> 
> That said; I still don't see the point of schedule_timeout_idle(), we
> should not sleep poll for state like that. We should only use TASK_IDLE
> when we are in fact _IDLE_ and do not have work to do, at which point
> one should use an wait_event() like construct to wait for new work.

        Probably. But some kthreads may want to sleep,
like in the IPVS case where there is a more complex
mechanism to wake up the kthread which is a socket writer
and does not poll the socket all time.

        But I see that kthreads always need to check with
kthread_should_stop(), so if we add schedule_timeout_idle()
it should not be so simple, may be something like that
is race free on kthread_stop() event, if needed at all:

/* state: TASK_IDLE (idle) or TASK_UNINTERRUPTIBLE (busy) */
kthread_schedule_timeout(timeout, state)
{
        /* note: no underscores => set_mb */
        set_current_state(state);
        /* test_bit after memory barrier */
        if (kthread_should_stop())
                return timeout;
        return schedule_timeout(timeout);
}

Regards

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

Reply via email to