Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751427AbcD2EQA (ORCPT ); Fri, 29 Apr 2016 00:16:00 -0400 Received: from mga04.intel.com ([192.55.52.120]:40907 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750736AbcD2EP7 (ORCPT ); Fri, 29 Apr 2016 00:15:59 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,549,1455004800"; d="scan'208";a="955281112" Date: Fri, 29 Apr 2016 04:34:05 +0800 From: Yuyang Du To: Peter Zijlstra Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, bsegall@google.com, pjt@google.com, morten.rasmussen@arm.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, lizefan@huawei.com, umgwanakikbuti@gmail.com Subject: Re: [PATCH v3 6/6] sched/fair: Move (inactive) option from code to config Message-ID: <20160428203405.GE16093@intel.com> References: <1459829551-21625-1-git-send-email-yuyang.du@intel.com> <1459829551-21625-7-git-send-email-yuyang.du@intel.com> <20160428093733.GX3430@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160428093733.GX3430@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1155 Lines: 24 On Thu, Apr 28, 2016 at 11:37:33AM +0200, Peter Zijlstra wrote: > On Tue, Apr 05, 2016 at 12:12:31PM +0800, Yuyang Du wrote: > > The option of increased load resolution (fixed point arithmetic range) is > > unconditionally deactivated with #if 0. But since it may still be used > > somewhere (e.g., in Google), we want to keep this option. > > > > Regardless, there should be a way to express this option. Considering the > > current circumstances, the reconciliation is we define a config > > CONFIG_CFS_INCREASE_LOAD_RANGE and it depends on FAIR_GROUP_SCHED and > > 64BIT and BROKEN. > > > > Suggested-by: Ingo Molnar > > So I'm very tempted to simply, unconditionally, reinstate this larger > range for everything CONFIG_64BIT && CONFIG_FAIR_GROUP_SCHED. > > There was but the single claim on increased power usage, nobody could > reproduce / analyze and Google has been running with this for years now. > > Furthermore, it seems to be leading to the obvious problems on bigger > machines where we basically run out of precision by the sheer number of > cpus (nr_cpus ~ SCHED_LOAD_SCALE and stuff comes apart quickly). Great.