From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Michael Turquette <mturquette@baylibre.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Juri Lelli <juri.lelli@arm.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Steve Muckle <steve.muckle@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks
Date: Tue, 8 Mar 2016 21:40:18 +0100 [thread overview]
Message-ID: <CAJZ5v0io2D6CBCfmnaBq5rPRpJWPQbkszs_y30NAXnX0c0hZQg@mail.gmail.com> (raw)
In-Reply-To: <20160308192400.4103.71868@quark.deferred.io>
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
next prev parent reply other threads:[~2016-03-08 20:40 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-29 22:52 [PATCH 0/3] cpufreq: Replace timers with utilization update callbacks Rafael J. Wysocki
2016-01-29 22:53 ` [PATCH 1/3] cpufreq: Add a mechanism for registering " Rafael J. Wysocki
2016-02-04 3:31 ` Viresh Kumar
2016-01-29 22:56 ` [PATCH 2/3] cpufreq: intel_pstate: Replace timers with " Rafael J. Wysocki
2016-01-29 22:59 ` [PATCH 3/3] cpufreq: governor: " Rafael J. Wysocki
2016-02-03 1:16 ` [Update][PATCH " Rafael J. Wysocki
2016-02-04 4:49 ` Viresh Kumar
2016-02-04 10:54 ` Rafael J. Wysocki
2016-02-05 1:28 ` [PATCH 3/3 v3] " Rafael J. Wysocki
2016-02-05 6:50 ` Viresh Kumar
2016-02-05 13:36 ` Rafael J. Wysocki
2016-02-05 14:47 ` Viresh Kumar
2016-02-05 23:10 ` Rafael J. Wysocki
2016-02-07 9:10 ` Viresh Kumar
2016-02-07 14:43 ` Rafael J. Wysocki
2016-02-08 2:08 ` Rafael J. Wysocki
2016-02-08 11:52 ` Viresh Kumar
2016-02-08 12:52 ` Rafael J. Wysocki
2016-02-08 13:40 ` Rafael J. Wysocki
2016-02-05 23:01 ` Rafael J. Wysocki
2016-02-06 3:40 ` [PATCH 3/3 v4] " Rafael J. Wysocki
2016-02-07 9:20 ` Viresh Kumar
2016-02-07 14:36 ` Rafael J. Wysocki
2016-02-07 14:50 ` [PATCH 3/3 v5] " Rafael J. Wysocki
2016-02-07 15:36 ` Viresh Kumar
2016-02-09 10:01 ` Gautham R Shenoy
2016-02-09 18:49 ` Rafael J. Wysocki
2016-02-03 22:20 ` [PATCH 0/3] cpufreq: " Rafael J. Wysocki
2016-02-04 0:08 ` Srinivas Pandruvada
2016-02-04 17:16 ` Rafael J. Wysocki
2016-02-04 10:51 ` Juri Lelli
2016-02-04 17:19 ` Rafael J. Wysocki
2016-02-08 23:06 ` Rafael J. Wysocki
2016-02-09 0:39 ` Steve Muckle
2016-02-09 1:01 ` Rafael J. Wysocki
2016-02-09 20:05 ` Rafael J. Wysocki
2016-02-10 1:02 ` Steve Muckle
2016-02-10 1:57 ` Rafael J. Wysocki
2016-02-10 3:09 ` Rafael J. Wysocki
2016-02-10 19:47 ` Steve Muckle
2016-02-10 21:49 ` Rafael J. Wysocki
2016-02-10 22:07 ` Steve Muckle
2016-02-10 22:12 ` Rafael J. Wysocki
2016-02-11 11:59 ` Peter Zijlstra
2016-02-11 12:24 ` Juri Lelli
2016-02-11 15:26 ` Peter Zijlstra
2016-02-11 18:23 ` Vincent Guittot
2016-02-12 14:04 ` Peter Zijlstra
2016-02-12 14:48 ` Vincent Guittot
2016-03-01 13:58 ` Peter Zijlstra
2016-03-01 14:17 ` Juri Lelli
2016-03-01 14:24 ` Peter Zijlstra
2016-03-01 14:26 ` Peter Zijlstra
2016-03-01 14:42 ` Juri Lelli
2016-03-01 15:04 ` Peter Zijlstra
2016-03-01 19:49 ` Rafael J. Wysocki
2016-03-01 14:58 ` Vincent Guittot
2016-02-11 17:06 ` Steve Muckle
2016-02-11 17:30 ` Peter Zijlstra
2016-02-11 17:34 ` Rafael J. Wysocki
2016-02-11 17:38 ` Peter Zijlstra
2016-02-11 18:52 ` Steve Muckle
2016-02-11 19:04 ` Rafael J. Wysocki
2016-02-12 13:43 ` Rafael J. Wysocki
2016-02-12 14:10 ` Peter Zijlstra
2016-02-12 16:01 ` Rafael J. Wysocki
2016-02-12 16:15 ` Rafael J. Wysocki
2016-02-12 16:53 ` Ashwin Chaugule
2016-02-12 23:14 ` Rafael J. Wysocki
2016-02-12 17:02 ` Doug Smythies
2016-02-12 23:17 ` Rafael J. Wysocki
2016-02-10 12:33 ` Juri Lelli
2016-02-10 13:23 ` Rafael J. Wysocki
2016-02-10 14:03 ` Juri Lelli
2016-02-10 14:26 ` Rafael J. Wysocki
2016-02-10 14:46 ` Juri Lelli
2016-02-10 15:46 ` Rafael J. Wysocki
2016-02-10 16:05 ` Juri Lelli
2016-02-11 11:51 ` Peter Zijlstra
2016-02-11 12:08 ` Rafael J. Wysocki
2016-02-11 15:29 ` Peter Zijlstra
2016-02-11 15:58 ` Rafael J. Wysocki
2016-02-11 20:47 ` Rafael J. Wysocki
2016-02-10 15:17 ` [PATCH v6 " Rafael J. Wysocki
2016-02-10 15:21 ` [PATCH v6 1/3] cpufreq: Add mechanism for registering " Rafael J. Wysocki
2016-02-10 23:01 ` [PATCH v7 " Rafael J. Wysocki
2016-02-11 17:30 ` [PATCH v8 " Rafael J. Wysocki
2016-02-12 13:16 ` [PATCH v9 " Rafael J. Wysocki
2016-02-15 21:47 ` [PATCH v10 " Rafael J. Wysocki
2016-02-18 20:22 ` Rafael J. Wysocki
2016-02-19 8:09 ` Juri Lelli
2016-02-19 16:42 ` Srinivas Pandruvada
2016-02-19 17:26 ` Juri Lelli
2016-02-19 22:26 ` Rafael J. Wysocki
2016-02-22 9:42 ` Juri Lelli
2016-02-22 21:41 ` Rafael J. Wysocki
2016-02-23 11:10 ` Juri Lelli
2016-02-24 1:52 ` Rafael J. Wysocki
2016-02-22 10:45 ` Viresh Kumar
2016-02-19 17:28 ` Steve Muckle
2016-02-19 22:35 ` Rafael J. Wysocki
2016-02-23 3:58 ` Steve Muckle
2016-02-22 10:52 ` Peter Zijlstra
2016-02-22 14:33 ` Vincent Guittot
2016-02-22 15:31 ` Peter Zijlstra
2016-02-22 14:40 ` Juri Lelli
2016-02-22 15:42 ` Peter Zijlstra
2016-02-22 21:46 ` Rafael J. Wysocki
2016-02-19 22:14 ` Rafael J. Wysocki
2016-02-22 9:32 ` Juri Lelli
2016-02-22 21:26 ` Rafael J. Wysocki
2016-02-23 11:01 ` Juri Lelli
2016-02-24 2:01 ` Rafael J. Wysocki
2016-03-08 19:24 ` Michael Turquette
2016-03-08 20:40 ` Rafael J. Wysocki [this message]
[not found] ` <20160308220632.4103.13377@quark.deferred.io>
2016-03-08 22:43 ` Rafael J. Wysocki
2016-03-09 12:35 ` Peter Zijlstra
2016-03-09 13:22 ` Rafael J. Wysocki
2016-03-09 13:32 ` Ingo Molnar
2016-03-09 13:39 ` Rafael J. Wysocki
2016-03-10 2:12 ` Vincent Guittot
2016-02-10 15:25 ` [PATCH v6 2/3] cpufreq: intel_pstate: Replace timers with " Rafael J. Wysocki
2016-02-10 15:36 ` [PATCH v6 3/3] cpufreq: governor: " Rafael J. Wysocki
2016-02-10 23:11 ` [PATCH v6 0/3] cpufreq: " Doug Smythies
2016-02-10 23:17 ` Rafael J. Wysocki
2016-02-11 22:50 ` Doug Smythies
2016-02-11 23:28 ` Rafael J. Wysocki
2016-02-12 1:02 ` Doug Smythies
2016-02-12 1:20 ` Rafael J. Wysocki
2016-02-12 7:25 ` Doug Smythies
2016-02-12 13:39 ` Rafael J. Wysocki
2016-02-12 17:33 ` Doug Smythies
2016-02-12 23:21 ` Rafael J. Wysocki
2016-02-11 6:02 ` Srinivas Pandruvada
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJZ5v0io2D6CBCfmnaBq5rPRpJWPQbkszs_y30NAXnX0c0hZQg@mail.gmail.com \
--to=rafael@kernel.org \
--cc=juri.lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mturquette@baylibre.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=steve.muckle@linaro.org \
--cc=tglx@linutronix.de \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).