Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1331275 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v6 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-10 16:40 +0100
    [PATCH v7 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-11 00:10 +0100
      [PATCH v8 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-11 18:30 +0100
        [PATCH v9 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-12 14:20 +0100
          [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-15 22:50 +0100
            Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks "Rafael J. Wysocki" <rafael@kernel.org> - 2016-02-18 21:30 +0100
              Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Juri Lelli <juri.lelli@arm.com> - 2016-02-19 09:10 +0100
                Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-02-19 17:50 +0100
                  Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Steve Muckle <steve.muckle@linaro.org> - 2016-02-19 18:30 +0100
                    Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-19 23:40 +0100
                      Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Steve Muckle <steve.muckle@linaro.org> - 2016-02-23 05:00 +0100
                    Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Peter Zijlstra <peterz@infradead.org> - 2016-02-22 12:00 +0100
                      Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Vincent Guittot <vincent.guittot@linaro.org> - 2016-02-22 15:40 +0100
                        Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Peter Zijlstra <peterz@infradead.org> - 2016-02-22 16:40 +0100
                      Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Juri Lelli <juri.lelli@arm.com> - 2016-02-22 15:40 +0100
                        Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Peter Zijlstra <peterz@infradead.org> - 2016-02-22 16:50 +0100
                      Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks "Rafael J. Wysocki" <rafael@kernel.org> - 2016-02-22 22:50 +0100
                  Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Juri Lelli <juri.lelli@arm.com> - 2016-02-19 18:30 +0100
                    Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-19 23:30 +0100
                      Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Juri Lelli <juri.lelli@arm.com> - 2016-02-22 10:50 +0100
                        Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks "Rafael J. Wysocki" <rafael@kernel.org> - 2016-02-22 22:50 +0100
                          Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Juri Lelli <juri.lelli@arm.com> - 2016-02-23 12:10 +0100
                            Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-24 03:00 +0100
                      Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2016-02-22 11:50 +0100
                Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-19 23:20 +0100
                  Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Juri Lelli <juri.lelli@arm.com> - 2016-02-22 10:40 +0100
                    Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks "Rafael J. Wysocki" <rafael@kernel.org> - 2016-02-22 22:30 +0100
                      Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks Juri Lelli <juri.lelli@arm.com> - 2016-02-23 12:10 +0100
                        Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-24 03:00 +0100

Page 2 of 2 — ← Prev page 1 [2]

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

On Mon, Feb 22, 2016 at 10:42 AM, Juri Lelli <juri.lelli@arm.com> wrote:
> Hi Rafael,
>
> On 19/02/16 23:26, Rafael J. Wysocki wrote:
>> On Friday, February 19, 2016 05:26:04 PM Juri Lelli wrote:
>> > Hi Srinivas,

[cut]

>> ---
>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Subject: [PATCH] cpufreq: Rework the scheduler hooks for triggering updates
>>
>> Commit fe7034338ba0 (cpufreq: Add mechanism for registering
>> utilization update callbacks) added cpufreq_update_util() to be
>> called by the scheduler (from the CFS part) on utilization updates.
>> The goal was to allow CFS to pass utilization information to cpufreq
>> and to trigger it to evaluate the frequency/voltage configuration
>> (P-state) of every CPU on a regular basis.
>>
>> However, the last two arguments of that function are never used by
>> the current code, so CFS might simply call cpufreq_trigger_update()
>> instead of it.
>>
>> For this reason, drop the last two arguments of cpufreq_update_util(),
>> rename it to cpufreq_trigger_update() and modify CFS to call it.
>>
>> Moreover, since the utilization is not involved in that now, rename
>> data types, functions and variables related to cpufreq_trigger_update()
>> to reflect that (eg. struct update_util_data becomes struct
>> freq_update_hook and so on).
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> This patch looks good to me. I didn't yet test it, but it shouldn't
> break things AFAICT.
>
> Thanks a lot for taking the time for this cleanup.

Alas, I don't think I will apply it.

Peter says that he wants the arguments to stay and he has a point IMO.

The very idea behind hooking up cpufreq to the scheduler through those
hooks has always been to make it possible to use the utilization
information provided by the scheduler in cpufreq.  As it turns out, we
can make significant improvements even *without* using that
information, because just having the hooks in there alone makes it
possible to simplify the code quite a bit in general and make it more
straightforward, but that's a *bonus* and not the objective. :-)

The objective still is to use the utilization numbers from the scheduler.

Both sched-freq and my approach agree on that, so I don't quite see
why I should pretend that this isn't the case now?

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

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

On 22/02/16 22:41, Rafael J. Wysocki wrote:
> On Mon, Feb 22, 2016 at 10:42 AM, Juri Lelli <juri.lelli@arm.com> wrote:
> > Hi Rafael,
> >
> > On 19/02/16 23:26, Rafael J. Wysocki wrote:
> >> On Friday, February 19, 2016 05:26:04 PM Juri Lelli wrote:
> >> > Hi Srinivas,
> 
> [cut]
> 
> >> ---
> >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >> Subject: [PATCH] cpufreq: Rework the scheduler hooks for triggering updates
> >>
> >> Commit fe7034338ba0 (cpufreq: Add mechanism for registering
> >> utilization update callbacks) added cpufreq_update_util() to be
> >> called by the scheduler (from the CFS part) on utilization updates.
> >> The goal was to allow CFS to pass utilization information to cpufreq
> >> and to trigger it to evaluate the frequency/voltage configuration
> >> (P-state) of every CPU on a regular basis.
> >>
> >> However, the last two arguments of that function are never used by
> >> the current code, so CFS might simply call cpufreq_trigger_update()
> >> instead of it.
> >>
> >> For this reason, drop the last two arguments of cpufreq_update_util(),
> >> rename it to cpufreq_trigger_update() and modify CFS to call it.
> >>
> >> Moreover, since the utilization is not involved in that now, rename
> >> data types, functions and variables related to cpufreq_trigger_update()
> >> to reflect that (eg. struct update_util_data becomes struct
> >> freq_update_hook and so on).
> >>
> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > This patch looks good to me. I didn't yet test it, but it shouldn't
> > break things AFAICT.
> >
> > Thanks a lot for taking the time for this cleanup.
> 
> Alas, I don't think I will apply it.
> 
> Peter says that he wants the arguments to stay and he has a point IMO.
> 
> The very idea behind hooking up cpufreq to the scheduler through those
> hooks has always been to make it possible to use the utilization
> information provided by the scheduler in cpufreq.  As it turns out, we
> can make significant improvements even *without* using that
> information, because just having the hooks in there alone makes it
> possible to simplify the code quite a bit in general and make it more
> straightforward, but that's a *bonus* and not the objective. :-)
> 
> The objective still is to use the utilization numbers from the scheduler.
> 
> Both sched-freq and my approach agree on that, so I don't quite see
> why I should pretend that this isn't the case now?
> 

As I said in the other reply, I'm not at all against having cpufreq
hooks in the scheduler. I was only wondering if deciding where such
hooks reside and which interface they have before we agreed on how they
will be used might cause problems in the future. :-)

Best,

- Juri

[toc] | [prev] | [next] | [standalone]

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

On Tuesday, February 23, 2016 11:10:07 AM Juri Lelli wrote:
> On 22/02/16 22:41, Rafael J. Wysocki wrote:
> > On Mon, Feb 22, 2016 at 10:42 AM, Juri Lelli <juri.lelli@arm.com> wrote:
> > > Hi Rafael,
> > >
> > > On 19/02/16 23:26, Rafael J. Wysocki wrote:
> > >> On Friday, February 19, 2016 05:26:04 PM Juri Lelli wrote:
> > >> > Hi Srinivas,
> > 
> > [cut]
> > 
> > >> ---
> > >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >> Subject: [PATCH] cpufreq: Rework the scheduler hooks for triggering updates
> > >>
> > >> Commit fe7034338ba0 (cpufreq: Add mechanism for registering
> > >> utilization update callbacks) added cpufreq_update_util() to be
> > >> called by the scheduler (from the CFS part) on utilization updates.
> > >> The goal was to allow CFS to pass utilization information to cpufreq
> > >> and to trigger it to evaluate the frequency/voltage configuration
> > >> (P-state) of every CPU on a regular basis.
> > >>
> > >> However, the last two arguments of that function are never used by
> > >> the current code, so CFS might simply call cpufreq_trigger_update()
> > >> instead of it.
> > >>
> > >> For this reason, drop the last two arguments of cpufreq_update_util(),
> > >> rename it to cpufreq_trigger_update() and modify CFS to call it.
> > >>
> > >> Moreover, since the utilization is not involved in that now, rename
> > >> data types, functions and variables related to cpufreq_trigger_update()
> > >> to reflect that (eg. struct update_util_data becomes struct
> > >> freq_update_hook and so on).
> > >>
> > >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > This patch looks good to me. I didn't yet test it, but it shouldn't
> > > break things AFAICT.
> > >
> > > Thanks a lot for taking the time for this cleanup.
> > 
> > Alas, I don't think I will apply it.
> > 
> > Peter says that he wants the arguments to stay and he has a point IMO.
> > 
> > The very idea behind hooking up cpufreq to the scheduler through those
> > hooks has always been to make it possible to use the utilization
> > information provided by the scheduler in cpufreq.  As it turns out, we
> > can make significant improvements even *without* using that
> > information, because just having the hooks in there alone makes it
> > possible to simplify the code quite a bit in general and make it more
> > straightforward, but that's a *bonus* and not the objective. :-)
> > 
> > The objective still is to use the utilization numbers from the scheduler.
> > 
> > Both sched-freq and my approach agree on that, so I don't quite see
> > why I should pretend that this isn't the case now?
> > 
> 
> As I said in the other reply, I'm not at all against having cpufreq
> hooks in the scheduler. I was only wondering if deciding where such
> hooks reside and which interface they have before we agreed on how they
> will be used might cause problems in the future. :-)

And I have said for a few times that I don't quite see what problems exactly
those might be.

Also having the hooks in there and with the util and max arguments allows
everybody to play with them and see what can be done and whether or not they
are suitable for particular purposes.  I've already sufficiently demonstrated
that they are generally useful I think.

And if they aren't suitable for a particular purpose, one can try different
types of changes and see what looks good, what's practical and what's not etc.
intel_pstate can do that, you can do that, I can look at that from the existing
cpufreq governors perspective and so on.  In other words, it facilitates future
development.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

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

On 19-02-16, 23:26, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Subject: [PATCH] cpufreq: Rework the scheduler hooks for triggering updates
> 
> Commit fe7034338ba0 (cpufreq: Add mechanism for registering
> utilization update callbacks) added cpufreq_update_util() to be
> called by the scheduler (from the CFS part) on utilization updates.
> The goal was to allow CFS to pass utilization information to cpufreq
> and to trigger it to evaluate the frequency/voltage configuration
> (P-state) of every CPU on a regular basis.
> 
> However, the last two arguments of that function are never used by
> the current code, so CFS might simply call cpufreq_trigger_update()
> instead of it.
> 
> For this reason, drop the last two arguments of cpufreq_update_util(),
> rename it to cpufreq_trigger_update() and modify CFS to call it.
> 
> Moreover, since the utilization is not involved in that now, rename
> data types, functions and variables related to cpufreq_trigger_update()
> to reflect that (eg. struct update_util_data becomes struct
> freq_update_hook and so on).
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  drivers/cpufreq/cpufreq.c          |   48 ++++++++++++++++++++++---------------
>  drivers/cpufreq/cpufreq_governor.c |   27 ++++++++++----------
>  drivers/cpufreq/cpufreq_governor.h |    2 -
>  drivers/cpufreq/intel_pstate.c     |   15 +++++------
>  include/linux/cpufreq.h            |   32 +++---------------------
>  kernel/sched/deadline.c            |    2 -
>  kernel/sched/fair.c                |   13 +---------
>  kernel/sched/rt.c                  |    2 -
>  8 files changed, 58 insertions(+), 83 deletions(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

[toc] | [prev] | [next] | [standalone]

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

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@rjwysocki.net> wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> 
> [...]
> 
> > 
> > So if anyone has any issues with this one, please let me know.
> > 
> 
> I'm repeating myself a bit, but I'll try to articulate my only concern
> once again anyway. I run some tests on a couple of arm boxes and I
> didn't notice any regression or improvements for ondemand and
> conservative (FWIW this might also work as a tested-by), so I tend to
> take this series as a way to replace governor timers, making further
> cleanups and fixes possibile. I think you already confirmed this and I
> understand why you'd like this series to go in as I also think that what
> we have on top is beneficial.

OK

> However, I still don't quite get why we want to introduce an interface
> for explicit passing of util and max if we are not using such parameters
> yet. Also, I couldn't find any indication of how such parameters will be
> used in the future. If what we need today is a periodic kick for cpufreq
> governors that need it, we should simply do how we already do for RT and
> DL, IMHO. Also because the places where the current hooks reside might
> not be the correct and useful one once we'll start using the utilization
> parameters. I could probably make a case for DL where we should place
> hooks in admission control path (or somewhere else when more
> sophisticated mechanisms we'll be in place) rather then in the periodic
> tick.

Well, the hook in DL is explicitly denoted as a temporary band-aid.

I and Srinivas have said for multiple times that we are going to use the
scheduler's utilization data in intel_pstate.  Admittedly, we haven't shown
any patches implementing that, but that's because Srinivas doesn't regard
that work as ready yet.

I also have something for the general cpufreq in the works.  I may be able
to send it as an RFC over the weekend, depending on how much time I can
spend on it.

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.

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.

> > It has been in linux-next for a few days and seems to be doing well.
> > 
> > As I said previously, there is a metric ton of cpufreq improvements
> > depending on it, so I'd rather not delay integrating it any more.
> > 
> 
> As said. I'm not against these changes since they open up to further
> substantial fixes.

Good. :-)

> I'm only wondering if we are doing the right thing defining an interface
> that nobody is using and without an indication of how such thing we'll be
> used in the future.

That indication may be coming though. :-)

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

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

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@rjwysocki.net> wrote:
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > >
> > 
> > [...]
> > 
> > > 
> > > So if anyone has any issues with this one, please let me know.
> > > 
> > 
> > I'm repeating myself a bit, but I'll try to articulate my only concern
> > once again anyway. I run some tests on a couple of arm boxes and I
> > didn't notice any regression or improvements for ondemand and
> > conservative (FWIW this might also work as a tested-by), so I tend to
> > take this series as a way to replace governor timers, making further
> > cleanups and fixes possibile. I think you already confirmed this and I
> > understand why you'd like this series to go in as I also think that what
> > we have on top is beneficial.
> 
> OK
> 
> > However, I still don't quite get why we want to introduce an interface
> > for explicit passing of util and max if we are not using such parameters
> > yet. Also, I couldn't find any indication of how such parameters will be
> > used in the future. If what we need today is a periodic kick for cpufreq
> > governors that need it, we should simply do how we already do for RT and
> > DL, IMHO. Also because the places where the current hooks reside might
> > not be the correct and useful one once we'll start using the utilization
> > parameters. I could probably make a case for DL where we should place
> > hooks in admission control path (or somewhere else when more
> > sophisticated mechanisms we'll be in place) rather then in the periodic
> > tick.
> 
> Well, the hook in DL is explicitly denoted as a temporary band-aid.
> 
> I and Srinivas have said for multiple times that we are going to use the
> scheduler's utilization data in intel_pstate.  Admittedly, we haven't shown
> any patches implementing that, but that's because Srinivas doesn't regard
> that work as ready yet.
> 
> I also have something for the general cpufreq in the works.  I may be able
> to send it as an RFC over the weekend, depending on how much time I can
> spend on it.
> 

Saw that, thanks. Please allow me some time to review and test. :-)

> 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.

> 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.
 
> > > It has been in linux-next for a few days and seems to be doing well.
> > > 
> > > As I said previously, there is a metric ton of cpufreq improvements
> > > depending on it, so I'd rather not delay integrating it any more.
> > > 
> > 
> > As said. I'm not against these changes since they open up to further
> > substantial fixes.
> 
> Good. :-)
> 
> > I'm only wondering if we are doing the right thing defining an interface
> > that nobody is using and without an indication of how such thing we'll be
> > used in the future.
> 
> That indication may be coming though. :-)
> 

Thanks again. I'm going to have a look at that.

Best,

- Juri

[toc] | [prev] | [next] | [standalone]

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

On Mon, Feb 22, 2016 at 10:32 AM, Juri Lelli <juri.lelli@arm.com> 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@rjwysocki.net> wrote:
>> > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> > > >

[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.

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.

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.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

On Tuesday, February 23, 2016 11:01:18 AM Juri Lelli wrote:
> On 22/02/16 22:26, Rafael J. Wysocki wrote:
> > On Mon, Feb 22, 2016 at 10:32 AM, Juri Lelli <juri.lelli@arm.com> 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@rjwysocki.net> wrote:
> > >> > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >> > > >
> > 
> > [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.

And that's fine.  If the current position and/or arguments are not suitable,
they'll need to be changed.  It's not like things introduced today are set
in stone forever.

Peter has already shown how they may be changed to make everyone happy,
so I don't really see what the fuss is about.

> > 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.

Sure, but this particular formula is very simple.  It just assumes that
util <= max so dividing the former by the latter will always yield a number
between 0 and 1.  [And the interpretation of util > max is totally arbitrary
today and regarded as temporary anyway, so that's just irrelevant.]

Thanks,
Rafael

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web