From: Quentin Perret <quentin.perret@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel <linux-kernel@vger.kernel.org>,
"open list:THERMAL" <linux-pm@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Ingo Molnar <mingo@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Chris Redpath <chris.redpath@arm.com>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Valentin Schneider <valentin.schneider@arm.com>,
Thara Gopinath <thara.gopinath@linaro.org>,
viresh kumar <viresh.kumar@linaro.org>,
Todd Kjos <tkjos@google.com>,
Joel Fernandes <joel@joelfernandes.org>,
"Cc: Steve Muckle" <smuckle@google.com>,
adharmap@quicinc.com, "Kannan, Saravana" <skannan@quicinc.com>,
pkondeti@codeaurora.org
Subject: Re: [RFC PATCH v4 12/12] OPTIONAL: cpufreq: dt: Register an Energy Model
Date: Mon, 30 Jul 2018 17:20:32 +0100 [thread overview]
Message-ID: <20180730162029.2bu3vqipajgelbyz@queper01-lin> (raw)
In-Reply-To: <CAKfTPtASCvv1sbzp-7N=dsFBjATaGdeorxiyZ9urDgsMO8+XGA@mail.gmail.com>
Hi Vincent,
On Monday 30 Jul 2018 at 17:53:23 (+0200), Vincent Guittot wrote:
[...]
> ok, so you copy/paste what is done in cpu cooling device ?
>
> Nevertheless I still have some concerns with the formula used here and
> in cpu cooling device:
>
> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/arm/cpus.txt#L273
> The documentation says
> Pdyn = dynamic-power-coefficient * V^2 * f where voltage is in uV,
> frequency is in MHz.
> and dynamic power coefficient in units of mW/MHz/uV^2.
>
> This implies that the results is in mW and we can summarize the formula with :
>
> mW = C * (uV)^2 * Mhz with C = dynamic-power-coefficient
> then uV = 1000*mV
> mW = C * (1000*mV)^2 * Mhz
> mW = C * 1000000 * mV * mV * Mhz
>
> Which is different from what is used here and in cpu cooling device.
> I may have done something wrong with the formula but i can't catch
> it... My brain is not yet fully back from vacations
I think your brain works fine ;) The doc does seem to be incorrect ...
I also believe that this issue has been discussed recently in another
thread:
http://archive.armlinux.org.uk/lurker/message/20180720.141530.2bf75d5c.en.html
> Which gives with the formula in the documentation:
> mW = 550 * (1100000)^2 * 2362 = 1,571911×10^18 which is quite huge
> even for a big core running at max freq
> and with the formula in cpu_cooling.c:
> mW = 550 * 1100 * 1100 * 2362 / 1000000000 = 1571 which seems to be a
> bit more reasonable
Indeed, 1.5W for a big CPU at max OPP is in the right ballpark I
believe.
FYI, this is the power values I have in the EM for all OPPs on H960:
+--------+-------+--------+--------+
| A53s | A73s |
+--------+-------+--------+--------+
| MHz | mW | MHz | mW |
+--------+-------+--------+--------+
| 533 | 28 | 903 | 243 |
| 999 | 70 | 1421 | 500 |
| 1402 | 124 | 1805 | 804 |
| 1709 | 187 | 2112 | 1161 |
| 1844 | 245 | 2362 | 1571 |
+--------+-------+--------+--------+
[...]
> It's just that the tests results that you provided in the cover letter
> has used this patch and running tests with wrong formula (it seems
> that's the documentation is wrong) doesn't give much confidence on the
> results
I can understand that the mismatch between the code and the
documentation can be slightly confusing. However, as you said yourself
the code _is_ correct, so the test results are valid.
Moreover, the actual unit for the power costs doesn't make any
difference with EAS as long as that doesn't cause precision issues. EAS
works in relative terms, so even if the unit was in, say, uW instead of
mW, the test results would still be valid. And again, that's not the
case, the code does the right thing here.
Thanks,
Quentin
prev parent reply other threads:[~2018-07-30 16:20 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-28 11:40 [RFC PATCH v4 00/12] Energy Aware Scheduling Quentin Perret
2018-06-28 11:40 ` [RFC PATCH v4 01/12] sched: Relocate arch_scale_cpu_capacity Quentin Perret
2018-06-28 11:40 ` [RFC PATCH v4 02/12] sched/cpufreq: Factor out utilization to frequency mapping Quentin Perret
2018-06-28 11:40 ` [RFC PATCH v4 03/12] PM: Introduce an Energy Model management framework Quentin Perret
2018-07-05 14:31 ` Peter Zijlstra
2018-07-05 15:24 ` Quentin Perret
2018-07-05 14:39 ` Peter Zijlstra
2018-07-05 15:09 ` Quentin Perret
2018-07-05 15:06 ` Peter Zijlstra
2018-07-05 15:32 ` Quentin Perret
2018-07-06 9:57 ` Vincent Guittot
2018-07-06 10:03 ` Peter Zijlstra
2018-07-06 10:06 ` Quentin Perret
2018-07-06 10:05 ` Quentin Perret
2018-07-09 18:07 ` Dietmar Eggemann
2018-07-10 8:32 ` Quentin Perret
2018-07-16 10:29 ` Quentin Perret
2018-07-17 8:57 ` Dietmar Eggemann
2018-07-17 14:19 ` Quentin Perret
2018-07-17 16:00 ` Dietmar Eggemann
2018-06-28 11:40 ` [RFC PATCH v4 04/12] PM / EM: Expose the Energy Model in sysfs Quentin Perret
2018-06-28 11:40 ` [RFC PATCH v4 05/12] sched/topology: Reference the Energy Model of CPUs when available Quentin Perret
2018-07-05 17:29 ` Peter Zijlstra
2018-07-05 17:48 ` Quentin Perret
2018-07-05 17:33 ` Peter Zijlstra
2018-07-05 17:50 ` Quentin Perret
2018-07-05 18:14 ` Peter Zijlstra
2018-06-28 11:40 ` [RFC PATCH v4 06/12] sched/topology: Lowest energy aware balancing sched_domain level pointer Quentin Perret
2018-06-28 11:40 ` [RFC PATCH v4 07/12] sched/topology: Introduce sched_energy_present static key Quentin Perret
2018-06-28 11:40 ` [RFC PATCH v4 08/12] sched: Add over-utilization/tipping point indicator Quentin Perret
2018-07-06 11:32 ` Peter Zijlstra
2018-07-06 13:20 ` Quentin Perret
2018-07-06 13:24 ` Peter Zijlstra
2018-07-06 13:40 ` Quentin Perret
2018-07-06 11:39 ` Peter Zijlstra
2018-07-06 11:41 ` Peter Zijlstra
2018-07-06 11:49 ` Valentin Schneider
2018-06-28 11:40 ` [RFC PATCH v4 09/12] sched/fair: Introduce an energy estimation helper function Quentin Perret
2018-07-06 13:12 ` Peter Zijlstra
2018-07-06 15:12 ` Quentin Perret
2018-07-06 15:49 ` Peter Zijlstra
2018-07-06 17:04 ` Quentin Perret
2018-07-09 12:01 ` Peter Zijlstra
2018-07-09 15:28 ` Quentin Perret
2018-07-09 15:42 ` Peter Zijlstra
2018-07-09 16:07 ` Quentin Perret
2018-07-06 15:50 ` Peter Zijlstra
2018-06-28 11:40 ` [RFC PATCH v4 10/12] sched/fair: Select an energy-efficient CPU on task wake-up Quentin Perret
2018-06-28 11:40 ` [RFC PATCH v4 11/12] OPTIONAL: arch_topology: Start Energy Aware Scheduling Quentin Perret
2018-06-28 11:40 ` [RFC PATCH v4 12/12] OPTIONAL: cpufreq: dt: Register an Energy Model Quentin Perret
2018-07-06 10:10 ` Vincent Guittot
2018-07-06 10:18 ` Quentin Perret
2018-07-30 15:53 ` Vincent Guittot
2018-07-30 16:20 ` Quentin Perret [this message]
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=20180730162029.2bu3vqipajgelbyz@queper01-lin \
--to=quentin.perret@arm.com \
--cc=adharmap@quicinc.com \
--cc=chris.redpath@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=pkondeti@codeaurora.org \
--cc=rjw@rjwysocki.net \
--cc=skannan@quicinc.com \
--cc=smuckle@google.com \
--cc=thara.gopinath@linaro.org \
--cc=tkjos@google.com \
--cc=valentin.schneider@arm.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).