Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759372AbcCDP64 (ORCPT ); Fri, 4 Mar 2016 10:58:56 -0500 Received: from mga09.intel.com ([134.134.136.24]:11394 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759277AbcCDP6s (ORCPT ); Fri, 4 Mar 2016 10:58:48 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,536,1449561600"; d="scan'208";a="916965635" Message-ID: <1457106973.4356.13.camel@linux.intel.com> Subject: Re: [PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data From: Srinivas Pandruvada To: Juri Lelli , "Rafael J. Wysocki" Cc: Linux PM list , Steve Muckle , ACPI Devel Maling List , Linux Kernel Mailing List , Peter Zijlstra , Viresh Kumar , Vincent Guittot , Michael Turquette , Ingo Molnar Date: Fri, 04 Mar 2016 07:56:13 -0800 In-Reply-To: <20160304112639.GD4061@e106622-lin> References: <2495375.dFbdlAZmA6@vostro.rjw.lan> <2409306.qzzMXcm4dm@vostro.rjw.lan> <4627718.FT18d2LR5p@vostro.rjw.lan> <20160304112639.GD4061@e106622-lin> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.3 (3.18.3-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2434 Lines: 62 On Fri, 2016-03-04 at 11:26 +0000, Juri Lelli wrote: > Hi Rafael, > > On 04/03/16 04:35, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Add a new cpufreq scaling governor, called "schedutil", that uses > > scheduler-provided CPU utilization information as input for making > > its decisions. > > > > Doing that is possible after commit fe7034338ba0 (cpufreq: Add > > mechanism for registering utilization update callbacks) that > > introduced cpufreq_update_util() called by the scheduler on > > utilization changes (from CFS) and RT/DL task status updates. > > In particular, CPU frequency scaling decisions may be based on > > the the utilization data passed to cpufreq_update_util() by CFS. > > > > The new governor is relatively simple. > > > > The frequency selection formula used by it is > > > > next_freq = util * max_freq / max > > > > where util and max are the utilization and CPU capacity coming from > > CFS. > > > > The formula looks better to me now. However, problem is that, if you > have freq. invariance, util will slowly saturate to the current > capacity. So, we won't trigger OPP changes for a task that for > example > starts light and then becomes big. > > This is the same problem we faced with schedfreq. The current > solution > there is to use a margin for calculating a threshold (80% of current > capacity ATM). Once util goes above that threshold we trigger an OPP > change.  Current policy is pretty aggressive, we go to max_f and then > adapt to the "real" util during successive enqueues. This was also > tought to cope with the fact that PELT seems slow to react to abrupt > changes in tasks behaviour. > I also tried something like this in intel_pstate with scheduler util, where you ramp up to turbo when a threshold percent exceeded then ramp down slowly in steps. This helped some workloads like tbench to perform better, but it resulted in lower performance/watt on specpower server workload. The problem is finding what is the right threshold value. Thanks, Srinivas > I'm not saying this is the definitive solution, but I fear something > along this line is needed when you add freq invariance in the mix. > > Best, > > - Juri > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" > in > the body of a message to majordomo@vger.kernel.org > More majordomo info at  http://vger.kernel.org/majordomo-info.html