From: Matthias Kaehlcke <mka@chromium.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Lukasz Luba <lukasz.luba@arm.com>,
Rob Herring <robh+dt@kernel.org>,
DTML <devicetree@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Amit Daniel Kachhap <amit.kachhap@gmail.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Javi Merino <javi.merino@kernel.org>
Subject: Re: is 'dynamic-power-coefficient' expected to be based on 'real' power measurements?
Date: Tue, 15 Sep 2020 14:51:43 -0700 [thread overview]
Message-ID: <20200915215143.GE2771744@google.com> (raw)
In-Reply-To: <CAD=FV=XPTrA0S5OukQT4=R7HCOd8DuJCdXCDKW+xCO6YNe7xNA@mail.gmail.com>
On Tue, Sep 15, 2020 at 02:46:16PM -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Sep 15, 2020 at 1:55 PM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
> >
> > On 15/09/2020 19:58, Matthias Kaehlcke wrote:
> > > On Tue, Sep 15, 2020 at 07:50:10PM +0200, Daniel Lezcano wrote:
> > >> On 15/09/2020 19:24, Matthias Kaehlcke wrote:
> > >>> +Thermal folks
> > >>>
> > >>> Hi Rajendra,
> > >>>
> > >>> On Tue, Sep 15, 2020 at 11:14:00AM +0530, Rajendra Nayak wrote:
> > >>>> Hi Rob,
> > >>>>
> > >>>> There has been some discussions on another thread [1] around the DPC (dynamic-power-coefficient) values
> > >>>> for CPU's being relative vs absolute (based on real power) and should they be used to derive 'real' power
> > >>>> at various OPPs in order to calculate things like 'sustainable-power' for thermal zones.
> > >>>> I believe relative values work perfectly fine for scheduling decisions, but with others using this for
> > >>>> calculating power values in mW, is there a need to document the property as something that *has* to be
> > >>>> based on real power measurements?
> > >>>
> > >>> Relative values may work for scheduling decisions, but not for thermal
> > >>> management with the power allocator, at least not when CPU cooling devices
> > >>> are combined with others that specify their power consumption in absolute
> > >>> values. Such a configuration should be supported IMO.
> > >>
> > >> The energy model is used in the cpufreq cooling device and if the
> > >> sustainable power is consistent with the relative values then there is
> > >> no reason it shouldn't work.
> > >
> > > Agreed on thermal zones that exclusively use CPUs as cooling devices, but
> > > what when you have mixed zones, with CPUs with their pseudo-unit and e.g. a
> > > GPU that specifies its power in mW?
> >
> > Well, if a SoC vendor decides to mix the units, then there is nothing we
> > can do.
>
> I mean, there is something someone could do. They could buy one of
> these devices, measure the power (which wouldn't actually be that hard
> to do), then submit a patch to adjust all the numbers. ;-)
In case they look for a recipe:
commit ac60c5e33df4ec2b69c7e3ebbc0ccf1557e7bd5e
Author: Matthias Kaehlcke <mka@chromium.org>
Date: Thu Apr 11 17:01:58 2019 -0700
ARM: dts: rockchip: Add dynamic-power-coefficient for rk3288
The value was determined with the following method:
- take CPUs 1-3 offline
- for each OPP
- set cpufreq min and max freq to OPP freq
- start dhrystone benchmark
- measure CPU power consumption during 10s
- calculate Cx for OPPx
- Cx = (Px - P1) / (Vx²fx - V1²f1) [1]
using the following units: mW / Ghz / V [2]
- C = avg(C2, ..., Cn)
[1] see commit 4daa001a1773 ("arm64: dts: juno: Add cpu
dynamic-power-coefficient information")
[2] https://patchwork.kernel.org/patch/10493615/#22158551
next prev parent reply other threads:[~2020-09-15 21:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-15 5:44 is 'dynamic-power-coefficient' expected to be based on 'real' power measurements? Rajendra Nayak
2020-09-15 17:24 ` Matthias Kaehlcke
2020-09-15 17:50 ` Daniel Lezcano
2020-09-15 17:58 ` Matthias Kaehlcke
2020-09-15 20:55 ` Daniel Lezcano
2020-09-15 21:13 ` Matthias Kaehlcke
2020-09-15 21:23 ` Daniel Lezcano
2020-09-15 21:36 ` Matthias Kaehlcke
2020-09-16 4:15 ` Rajendra Nayak
2020-09-16 16:40 ` Matthias Kaehlcke
2020-09-15 21:46 ` Doug Anderson
2020-09-15 21:51 ` Matthias Kaehlcke [this message]
2020-09-16 9:53 ` Lukasz Luba
2020-09-16 16:48 ` Matthias Kaehlcke
2020-09-24 6:09 ` Rajendra Nayak
2020-09-24 8:21 ` Lukasz Luba
2020-09-16 9:18 ` Lukasz Luba
2020-09-15 19:53 ` Doug Anderson
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=20200915215143.GE2771744@google.com \
--to=mka@chromium.org \
--cc=amit.kachhap@gmail.com \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=javi.merino@kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=rnayak@codeaurora.org \
--cc=robh+dt@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.