linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>,
	Lukasz Luba <lukasz.luba@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	DTML <devicetree@vger.kernel.org>,
	Doug Anderson <dianders@chromium.org>,
	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:13:09 -0700	[thread overview]
Message-ID: <20200915211309.GC2771744@google.com> (raw)
In-Reply-To: <27785351-ba14-dc92-6761-d64962c29596@linaro.org>

On Tue, Sep 15, 2020 at 10:55:52PM +0200, Daniel Lezcano 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.
> 
> When specifying the power numbers available for the SoC, they could be
> all scaled against the highest power number.

The GPU was just one example, a device could have heat dissipating components
that are not from the SoC vendor (e.g. WiFi, modem, backlight), and depending
on the design it might not make sense to have separate thermal zones.

> There are so many factors on the hardware, the firmware, the kernel and
> the userspace sides having an impact on the energy efficiency, I don't
> understand why SoC vendors are so shy to share the power numbers...

nor do I, someone could just perform measurements to determine DPCs
with the proper scale if Qualcomm refuses to provide them ...

  reply	other threads:[~2020-09-15 21:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <248bb01e-1746-c84c-78c4-3cf7d2541a70@codeaurora.org>
2020-09-15 17:24 ` is 'dynamic-power-coefficient' expected to be based on 'real' power measurements? 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 [this message]
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
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=20200915211309.GC2771744@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 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).