From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752374AbcBWLAX (ORCPT ); Tue, 23 Feb 2016 06:00:23 -0500 Received: from foss.arm.com ([217.140.101.70]:36250 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750746AbcBWLAV (ORCPT ); Tue, 23 Feb 2016 06:00:21 -0500 Date: Tue, 23 Feb 2016 11:01:18 +0000 From: Juri Lelli To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Linux PM list , Peter Zijlstra , Ingo Molnar , Linux Kernel Mailing List , Srinivas Pandruvada , Viresh Kumar , Steve Muckle , Thomas Gleixner Subject: Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks Message-ID: <20160223110118.GJ27380@e106622-lin> References: <3071836.JbNxX8hU6x@vostro.rjw.lan> <20160219080917.GE22643@pablo> <5324745.ObXn8lTQ9A@vostro.rjw.lan> <20160222093244.GB27380@e106622-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On 22/02/16 22:26, Rafael J. Wysocki wrote: > On Mon, Feb 22, 2016 at 10:32 AM, Juri Lelli wrote: > > On 19/02/16 23:14, Rafael J. Wysocki wrote: > >> On Friday, February 19, 2016 08:09:17 AM Juri Lelli wrote: > >> > Hi Rafael, > >> > > >> > On 18/02/16 21:22, Rafael J. Wysocki wrote: > >> > > On Mon, Feb 15, 2016 at 10:47 PM, Rafael J. Wysocki wrote: > >> > > > From: Rafael J. Wysocki > >> > > > > > [cut] > > >> That said, if the concern is that there are plans to change the way the > >> scheduler computes the utilization numbers and that may become difficult to > >> carry out if cpufreq starts to depend on them in their current form, then I > >> may agree that it is valid, but I'm not aware of those plans ATM. > >> > > > > No, I don't think there's any substantial discussion going on about the > > utilization numbers. > > OK, so the statement below applies. > > >> However, if the numbers are going to stay what they are, I don't see why > >> passing them to cpufreq may possibly become problematic at any point. > > > > My concern was mostly on the fact that there is already another RFC > > under discussion that uses the same numbers and has different hooks > > placed in scheduler code (Steve's sched-freq); so, additional hooks > > might generate confusion, IMHO. > > So this is about the hooks rather than about their arguments after > all, isn't it? > > I fail to see why it is better to drop the arguments and leave the hooks, then. > It's about where we place such hooks and what arguments they have. Without the schedutil governor as a consumer the current position makes sense, but some of the arguments are not used. With schedutil both position and arguments make sense, but a different implementation (sched-freq) might have different needs w.r.t. position and arguments. > OTOH, I see reasons for keeping the arguments along with the hooks, > but let me address that in my next reply. > > Now, if the call sites of the hooks change in the future, it won't be > a problem for me as long as the new hooks are invoked on a regular > basis or, if they aren't, as long as I can figure out from the > arguments they pass that I should not expect an update any time soon. > OK. > If the arguments change, it won't be a problem either as long as they > are sufficient to be inserted into the frequency selection formula > used by the schedutil governor I posted and produce sensible > frequencies for the CPU. > Right, I guess this applies to any kind of governor. Best, - Juri