Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753935AbbEMHY2 (ORCPT ); Wed, 13 May 2015 03:24:28 -0400 Received: from ja.ssi.bg ([178.16.129.10]:48578 "EHLO ja.ssi.bg" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751686AbbEMHYZ (ORCPT ); Wed, 13 May 2015 03:24:25 -0400 Date: Wed, 13 May 2015 10:22:23 +0300 (EEST) From: Julian Anastasov To: Peter Zijlstra cc: Ingo Molnar , Linus Torvalds , Oleg Nesterov , linux-kernel@vger.kernel.org, neilb@suse.de Subject: Re: [PATCH] sched: Introduce TASK_NOLOAD and TASK_IDLE In-Reply-To: <20150512122545.GN21418@twins.programming.kicks-ass.net> Message-ID: References: <20150508124748.GH27504@twins.programming.kicks-ass.net> <20150511142247.GT27504@twins.programming.kicks-ass.net> <20150512122545.GN21418@twins.programming.kicks-ass.net> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2079 Lines: 58 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 -- 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/