Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758718AbcCVMdY (ORCPT ); Tue, 22 Mar 2016 08:33:24 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36431 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756546AbcCVMdR (ORCPT ); Tue, 22 Mar 2016 08:33:17 -0400 Date: Tue, 22 Mar 2016 13:33:14 +0100 From: Michal Hocko To: Peter Zijlstra Cc: Andrew Morton , linux-mm@kvack.org, LKML , Tetsuo Handa , David Rientjes , Ingo Molnar Subject: Re: [PATCH 1/9] sched: add schedule_timeout_idle() Message-ID: <20160322123314.GD10381@dhcp22.suse.cz> References: <1458644426-22973-1-git-send-email-mhocko@kernel.org> <1458644426-22973-2-git-send-email-mhocko@kernel.org> <20160322122345.GN6344@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160322122345.GN6344@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1198 Lines: 34 On Tue 22-03-16 13:23:45, Peter Zijlstra wrote: > On Tue, Mar 22, 2016 at 12:00:18PM +0100, Michal Hocko wrote: > > > extern signed long schedule_timeout_interruptible(signed long timeout); > > extern signed long schedule_timeout_killable(signed long timeout); > > extern signed long schedule_timeout_uninterruptible(signed long timeout); > > +extern signed long schedule_timeout_idle(signed long timeout); > > > +/* > > + * Like schedule_timeout_uninterruptible(), except this task will not contribute > > + * to load average. > > + */ > > +signed long __sched schedule_timeout_idle(signed long timeout) > > +{ > > + __set_current_state(TASK_IDLE); > > + return schedule_timeout(timeout); > > +} > > +EXPORT_SYMBOL(schedule_timeout_idle); > > Yes we have 3 such other wrappers, but I've gotta ask: why? They seem > pretty pointless. It seems it is just too easy to miss the __set_current_state (I am talking from my own experience). This also seems to be a pretty common pattern so why not wrap it under a common call. > Why not kill the lot? We have over 400 users, would it be much better if we open code all of them? It doesn't sound like a huge win to me. -- Michal Hocko SUSE Labs