Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks

[Juri Lelli]

On 22/02/16 22:26, Rafael J. Wysocki wrote:
> On Mon, Feb 22, 2016 at 10:32 AM, Juri Lelli <juri.lelli@xxxxxxx> 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 <rjw@xxxxxxxxxxxxx> wrote:
> >> > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> >> > > >
> 
> [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