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

Groups > linux.kernel > #1353333 > unrolled thread

Re: [PATCH v10 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

  Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization  update callbacks Michael Turquette <mturquette@baylibre.com> - 2016-03-08 20:40 +0100
    Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-08 21:50 +0100
      Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering  utilization update callbacks "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-08 23:50 +0100

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

Quoting Rafael J. Wysocki (2016-02-23 18:01:06)
> 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.

I see this patch in linux-next now. Did it ever get Peter's or Ingo's
Ack?

Also it seems weird to me that this patch touching sched code is going
through the pm tree.

When it comes times to experiment more with the interfaces and make the
"future changes" that everyone keeps talking about, who is the
maintainer? Who has the last word?

Regards,
Mike

> 
> > > 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
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [next] | [standalone]

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

On Tue, Mar 8, 2016 at 8:24 PM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2016-02-23 18:01:06)
>> 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.
>
> I see this patch in linux-next now. Did it ever get Peter's or Ingo's
> Ack?

No, but none of them said "no" either.

And the interface was suggested by Peter in the first place.

> Also it seems weird to me that this patch touching sched code is going
> through the pm tree.

That's for purely practical reasons.  There are lots of PM changes
depending on it that have nothing to do with the scheduler.  I've been
talking about that for several times now, last time in my yesterday
post (http://marc.info/?l=linux-pm&m=145740561402948&w=2).  I've been
talking openly about what I'm going to do with this all the time.

No one is hiding things from anyone or trying to slip them through
past somebody here if that's what you're worried about.

> When it comes times to experiment more with the interfaces and make the
> "future changes" that everyone keeps talking about, who is the
> maintainer? Who has the last word?

As usual, it is about consensus.

This is on a boundary of two subsystems and I have good reasons to do
it.  One of the maintainers of the other subsystem involved is working
with me all the time and I'm following his suggestions.  Isn't that
really sufficient?

But really please see
http://marc.info/?l=linux-pm&m=145740561402948&w=2 as it means I'm
actually going to do what Juri and Steve asked for unless I'm told
that this is a bad idea.

Thanks,
Rafael

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

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

On Tue, Mar 8, 2016 at 11:06 PM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2016-03-08 12:40:18)
>> On Tue, Mar 8, 2016 at 8:24 PM, Michael Turquette
>> <mturquette@baylibre.com> wrote:
>> > Quoting Rafael J. Wysocki (2016-02-23 18:01:06)
>> >> 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.
>> >
>> > I see this patch in linux-next now. Did it ever get Peter's or Ingo's
>> > Ack?
>>
>> No, but none of them said "no" either.
>>
>> And the interface was suggested by Peter in the first place.
>>
>> > Also it seems weird to me that this patch touching sched code is going
>> > through the pm tree.
>>
>> That's for purely practical reasons.  There are lots of PM changes
>> depending on it that have nothing to do with the scheduler.  I've been
>> talking about that for several times now, last time in my yesterday
>> post (http://marc.info/?l=linux-pm&m=145740561402948&w=2).  I've been
>> talking openly about what I'm going to do with this all the time.
>>
>> No one is hiding things from anyone or trying to slip them through
>> past somebody here if that's what you're worried about.
>>
>> > When it comes times to experiment more with the interfaces and make the
>> > "future changes" that everyone keeps talking about, who is the
>> > maintainer? Who has the last word?
>>
>> As usual, it is about consensus.
>
> To be fair, that consensus should be recorded formally by Reviewed-by
> and Acked-by tags.

I would feel much more comfortable with ACKs on the commits touching
the scheduler code, no question about that. :-)

That said, if another maintainer makes PM-related or ACPI-related
changes and follows my suggestions all the way through, I may not feel
like I have to ACK all of that every time.  After all, it all boils
down to what happens to the pull request eventually and Acked-by tags
may or may not help there.

>>
>> This is on a boundary of two subsystems and I have good reasons to do
>> it.  One of the maintainers of the other subsystem involved is working
>> with me all the time and I'm following his suggestions.  Isn't that
>> really sufficient?
>>
>> But really please see
>> http://marc.info/?l=linux-pm&m=145740561402948&w=2 as it means I'm
>> actually going to do what Juri and Steve asked for unless I'm told
>> that this is a bad idea.
>
> I'll take a look. Note that Steve, Juri and Vincent are all at a
> conference this week so their responses may be slow.

That's fine.

I'm not going to send new versions of the patches any time soon
(unless somebody points out a problem to fix in them to me).

Thanks,
Rafael

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web