Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751484AbcCHUGD (ORCPT ); Tue, 8 Mar 2016 15:06:03 -0500 Received: from mail-lb0-f195.google.com ([209.85.217.195]:33998 "EHLO mail-lb0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751428AbcCHUFw (ORCPT ); Tue, 8 Mar 2016 15:05:52 -0500 MIME-Version: 1.0 In-Reply-To: <20160308192640.GD6344@twins.programming.kicks-ass.net> References: <2495375.dFbdlAZmA6@vostro.rjw.lan> <56D8AEB7.2050100@linaro.org> <36459679.vzZnOsAVeg@vostro.rjw.lan> <20160308112759.GF6356@twins.programming.kicks-ass.net> <20160308192640.GD6344@twins.programming.kicks-ass.net> Date: Tue, 8 Mar 2016 21:05:50 +0100 X-Google-Sender-Auth: hQCh8EFCR2O_TASeO0gE9GvDydg Message-ID: Subject: Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data From: "Rafael J. Wysocki" To: Peter Zijlstra Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Steve Muckle , Vincent Guittot , Linux PM list , Juri Lelli , ACPI Devel Maling List , Linux Kernel Mailing List , Srinivas Pandruvada , Viresh Kumar , Michael Turquette , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3167 Lines: 83 On Tue, Mar 8, 2016 at 8:26 PM, Peter Zijlstra wrote: > On Tue, Mar 08, 2016 at 07:00:57PM +0100, Rafael J. Wysocki wrote: >> On Tue, Mar 8, 2016 at 12:27 PM, Peter Zijlstra wrote: > >> > Seeing how frequency invariance is an arch feature, and cpufreq drivers >> > are also typically arch specific, do we really need a flag at this >> > level? >> >> The next frequency is selected by the governor and that's why. The >> driver gets a frequency to set only. >> >> Now, the governor needs to work with different platforms, so it needs >> to know how to deal with the given one. > > Ah, indeed. In any case, the availability of arch_sched_scale_freq() is > a compile time thingy, so we can, at compile time, know what to use. > >> > In any case, I think the only difference between the two formula should >> > be the addition of (1) for the platforms that do not already implement >> > frequency invariance. >> >> OK >> >> So I'm reading this as a statement that linear is a better >> approximation for frequency invariant utilization. > > Well, (1) is what the scheduler does with frequency invariance, except > that allows a more flexible definition of 'current frequency' by asking > for it every time we update the util stats. > > But if a platform doesn't need this, ie. it has a fixed frequency, or > simply doesn't provide anything like this, assuming we run at the > frequency we asked for is a reasonable assumption no? > >> This means that on platforms where the utilization is frequency >> invariant we should use >> >> next_freq = a * x >> >> (where x is given by (2) above) and for platforms where the >> utilization is not frequency invariant >> >> next_freq = a * x * current_freq / max_freq >> >> and all boils down to finding a. > > Right. However, that doesn't seem to be in agreement with the Steve's results posted earlier in this thread. Also theoretically, with frequency invariant, the only way you can get to 100% utilization is by running at the max frequency, so the closer to 100% you get, the faster you need to run to get any further. That indicates nonlinear to me. >> Now, it seems reasonable for a to be something like (1 + 1/n) * >> max_freq, so for non-frequency invariant we get >> >> nex_freq = (1 + 1/n) * current_freq * x > > This seems like a big leap; where does: > > (1 + 1/n) * max_freq > > come from? And what is 'n'? a = max_freq gives next_freq = max_freq for x = 1, but with that choice of a you may never get to x = 1 with frequency invariant because of the feedback effect mentioned above, so the 1/n produces the extra boost needed for that (n is a positive integer). Quite frankly, to me it looks like linear really is a better approximation for "raw" utilization. That is, for frequency invariant x we should take: next_freq = a * x * max_freq / current_freq (and if x is not frequency invariant, the right-hand side becomes a * x). Then, the extra boost needed to get to x = 1 for frequency invariant is produced by the (max_freq / current_freq) factor that is greater than 1 as long as we are not running at max_freq and a can be chosen as max_freq.