From: Eduardo Valentin <edubezval@gmail.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
Ionela Voinescu <ionela.voinescu@arm.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Amit Daniel Kachhap <amit.kachhap@gmail.com>,
Javi Merino <javi.merino@kernel.org>,
Zhang Rui <rui.zhang@intel.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>,
Linux PM <linux-pm@vger.kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
lukasz.luba@arm.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Javi Merino <javi.merino@arm.com>,
Punit Agrawal <punit.agrawal@arm.com>
Subject: Re: [PATCH 4/4] cpu_cooling: Drop static-power related stuff
Date: Thu, 16 Nov 2017 15:44:24 -0800 [thread overview]
Message-ID: <20171116234422.GA6141@localhost.localdomain> (raw)
In-Reply-To: <2810372.fJ2vMN0cWO@aspire.rjw.lan>
Hello,
On Fri, Nov 17, 2017 at 12:31:41AM +0100, Rafael J. Wysocki wrote:
> On Thursday, November 16, 2017 4:20:58 PM CET Viresh Kumar wrote:
> > On 16-11-17, 15:02, Ionela Voinescu wrote:
> > > When it was added in lsk 3.18 in what was then a thermal driver for Juno
> > > it was believed to have an effect in thermal mitigation, but that was
> > > not proven later as to justify posting it upstream, and that is why the
> > > code never made it in mainline.
Really? Do you have data that can be shared to back up the above
statement?
Last time I checked, not only in Juno, static power does have
a non-negligible contribution. Neglecting static power can essentially
make IPA to undershoot in many cases to eventually overshoot. And that
is what I recollect from the data that I was presented, even for getting
this code reviewed. Just do not recollect to have the link to it.
> > > The code added there can be found at:
> > > https://git.linaro.org/landing-teams/working/arm/kernel-release.git/tree/drivers/thermal/scpi-thermal.c?h=lsk-3.18-armlt#n247
> > >
> > > As for removing this code now, I would not want to make that decision without
> > > spending more time to check if it impacts other customer codelines.
> > >
Maybe this is a matter of Linaro/ARM failing to convince SoC vendors to
really publish static power to mainline Linux instead of really having
the benefit of modeling it? Even simple models based on temperature
ranges would be better than only using dynamic power model.
> > > I'll come back with a reply to this in the next couple of days.
> >
> > Sure, we can wait for few days definitely :)
>
> While the above certainly is true, it doesn't matter whether or not any
> out-of-the-tree code will be affected by removing this from the mainline.
>
> What matters is *only* whether or not anyone is going to add anything
> depending on it to the mainline any time soon. If that's not the case,
> the stuff goes away (and may be added back in the future if need be).
>
> To avoid delaying this indefinitely, let's make a deal as follows.
>
> Unless anyone with some changes targeted at the mainline and depending on the
> code in question shows up before the end of the merge window currently under
> way, I will queue up the patches from Viresh for 4.16. Then, there will be
> 8 weeks (or more) of time before the 4.16 merge window opens to drop them if
> any new material depending on the code removed by them materializes in the
> meantime.
Sure, as I mentioned before, if we failed to convince SoC manufacturers
to provide valid models, makes no sense to keep dead code in the tree,
you have my support and you can add my:
Acked-by: Eduardo Valentin <edubezval@gmail.com>
I am just not convinced that this is really about the static power
being negligible for IPA.
>
> Thanks,
> Rafael
>
next prev parent reply other threads:[~2017-11-16 23:44 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 9:19 [PATCH 0/4] cpu_cooling: cooling dev registration cleanups Viresh Kumar
2017-11-15 9:19 ` [PATCH 1/4] cpu_cooling: Make of_cpufreq_power_cooling_register() parse DT Viresh Kumar
2017-11-15 9:19 ` [PATCH 2/4] cpu_cooling: Remove unused cpufreq_power_cooling_register() Viresh Kumar
2017-11-15 9:19 ` [PATCH 3/4] cpu_cooling: Keep only one of_cpufreq*cooling_register() helper Viresh Kumar
2017-11-15 9:19 ` [PATCH 4/4] cpu_cooling: Drop static-power related stuff Viresh Kumar
2017-11-15 10:18 ` Daniel Lezcano
2017-11-15 11:25 ` Viresh Kumar
2017-11-15 15:43 ` Eduardo Valentin
2017-11-15 18:17 ` Rafael J. Wysocki
2017-11-15 18:20 ` Eduardo Valentin
2017-11-16 15:02 ` Ionela Voinescu
2017-11-16 15:20 ` Viresh Kumar
2017-11-16 23:31 ` Rafael J. Wysocki
2017-11-16 23:44 ` Eduardo Valentin [this message]
2017-11-17 11:02 ` Punit Agrawal
2017-11-17 11:06 ` Viresh Kumar
2017-11-21 11:30 ` Ionela Voinescu
2017-11-21 13:06 ` Daniel Lezcano
2017-11-21 15:56 ` Lukasz Luba
2017-11-21 16:08 ` Vincent Guittot
2017-11-21 16:57 ` Eduardo Valentin
2017-11-21 18:00 ` Javi Merino
2017-11-21 18:05 ` Daniel Lezcano
2017-11-21 18:13 ` Eduardo Valentin
2017-11-21 23:32 ` Lukasz Luba
2017-11-21 18:12 ` Eduardo Valentin
2017-11-22 10:59 ` Sudeep Holla
2017-11-22 11:10 ` Viresh Kumar
2017-11-22 11:17 ` Sudeep Holla
2017-11-22 15:38 ` Eduardo Valentin
2017-11-22 15:34 ` Eduardo Valentin
2017-11-22 16:04 ` Sudeep Holla
2017-11-22 1:25 ` Viresh Kumar
2017-11-22 11:08 ` Viresh Kumar
2017-11-21 17:03 ` Lukasz Luba
2017-11-21 17:09 ` Eduardo Valentin
2017-11-21 17:49 ` Daniel Lezcano
2017-11-16 2:47 ` Viresh Kumar
2017-11-17 7:55 ` Daniel Lezcano
2017-11-15 11:31 ` Javi Merino
2017-11-15 11:39 ` Daniel Lezcano
2017-11-15 15:09 ` Eduardo Valentin
2017-11-15 18:08 ` [PATCH 0/4] cpu_cooling: cooling dev registration cleanups Rafael J. Wysocki
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=20171116234422.GA6141@localhost.localdomain \
--to=edubezval@gmail.com \
--cc=amit.kachhap@gmail.com \
--cc=daniel.lezcano@linaro.org \
--cc=ionela.voinescu@arm.com \
--cc=javi.merino@arm.com \
--cc=javi.merino@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mingo@redhat.com \
--cc=punit.agrawal@arm.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=rui.zhang@intel.com \
--cc=vincent.guittot@linaro.org \
--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 NNTP newsgroup(s).