On 22/02/16 22:26, Rafael J. Wysocki wrote: > On Mon, Feb 22, 2016 at 10:32 AM, Juri Lelli <[email protected]> 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 > >> > > <[email protected]> wrote: > >> > > > From: Rafael J. Wysocki <[email protected]> > >> > > > > > [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
