Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756033AbcCDLZm (ORCPT ); Fri, 4 Mar 2016 06:25:42 -0500 Received: from foss.arm.com ([217.140.101.70]:43443 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750919AbcCDLZf (ORCPT ); Fri, 4 Mar 2016 06:25:35 -0500 Date: Fri, 4 Mar 2016 11:26:39 +0000 From: Juri Lelli To: "Rafael J. Wysocki" Cc: Linux PM list , Steve Muckle , ACPI Devel Maling List , Linux Kernel Mailing List , Peter Zijlstra , Srinivas Pandruvada , Viresh Kumar , Vincent Guittot , Michael Turquette , Ingo Molnar Subject: Re: [PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data Message-ID: <20160304112639.GD4061@e106622-lin> References: <2495375.dFbdlAZmA6@vostro.rjw.lan> <2409306.qzzMXcm4dm@vostro.rjw.lan> <4627718.FT18d2LR5p@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4627718.FT18d2LR5p@vostro.rjw.lan> 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: 1709 Lines: 44 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'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