From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757518AbcBWHUi (ORCPT ); Tue, 23 Feb 2016 02:20:38 -0500 Received: from mail-pa0-f41.google.com ([209.85.220.41]:33864 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757388AbcBWHUf (ORCPT ); Tue, 23 Feb 2016 02:20:35 -0500 Subject: Re: [RFC/RFT][PATCH 1/1] cpufreq: New governor using utilization data from the scheduler To: "Rafael J. Wysocki" , Juri Lelli References: <5059413.77KZsd2lep@vostro.rjw.lan> <2004800.S71i79juRi@vostro.rjw.lan> <20160222141639.GF27380@e106622-lin> Cc: "Rafael J. Wysocki" , Linux PM list , Linux Kernel Mailing List , Viresh Kumar , Srinivas Pandruvada , Peter Zijlstra , Ingo Molnar From: Steve Muckle X-Enigmail-Draft-Status: N1110 Message-ID: <56CC0841.1@linaro.org> Date: Mon, 22 Feb 2016 23:20:33 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/22/2016 03:02 PM, Rafael J. Wysocki wrote: >> I guess the first (macro) question is why did you decide to go with a >> complete new governor, where new here is w.r.t. the sched-freq solution. > > Probably the most comprehensive answer to this question is my intro > message: http://marc.info/?l=linux-pm&m=145609673008122&w=2 > > The executive summary is probably that this was the most > straightforward way to use the scheduler-provided numbers in cpufreq > that I could think about. > >> AFAICT, it is true that your solution directly builds on top of the >> latest changes to cpufreq core and governor, but it also seems to have >> more than a few points in common with sched-freq, > > That surely isn't a drawback, is it? > > If two people come to the same conclusions in different ways, that's > an indication that the conclusions may actually be correct. > >> and sched-freq has been discussed and evaluated for already quite some time. > > Yes, it has. > > Does this mean that no one is allowed to try any alternatives to it now? As mentioned above they are rather similar so it doesn't really seem like an alternative per se, more like a reimplementation. Why do you feel a new starting point for this problem is needed? Are there specific technical concerns? I see you started looking over the latest schedfreq RFC, thank you for your comments thus far. We'd really appreciate your continued feedback and the chance to collaborate on it to move it forward. I and others have put a fair bit of effort into it over the last year or so and will happily and earnestly work to address any shortcomings you raise. I will review your RFC in the next day or so as well. ... > My goal, that may be quite different from yours, is to reduce the > cpufreq's overhead as much as I possibly can. If I have to change the > way it drives the CPU frequency selection to achieve that goal, I will > do that, but if that can stay the way it is, that's fine too. Our primary goal has been simply to achieve functional scheduler-driven CPU frequency control with equivalent or better power and performance than what is available today. Reduction of cpufreq overhead fits within this goal (and may be required) so no conflict here. thanks, Steve