From: Matthias Kaehlcke <mka@chromium.org>
To: Lukasz Luba <lukasz.luba@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
amit.kachhap@gmail.com, daniel.lezcano@linaro.org,
viresh.kumar@linaro.org, rafael@kernel.org, amitk@kernel.org,
rui.zhang@intel.com, dietmar.eggemann@arm.com,
Pierre.Gondois@arm.com, Douglas Anderson <dianders@chromium.org>,
Stephen Boyd <swboyd@chromium.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [PATCH 1/2] thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling
Date: Mon, 7 Feb 2022 16:50:22 -0800 [thread overview]
Message-ID: <YgG+TmLrCSXX4Bvt@google.com> (raw)
In-Reply-To: <20220207073036.14901-2-lukasz.luba@arm.com>
On Mon, Feb 07, 2022 at 07:30:35AM +0000, Lukasz Luba wrote:
> The Energy Model supports power values either in Watts or in some abstract
> scale. When the 2nd option is in use, the thermal governor IPA should not
> be allowed to operate, since the relation between cooling devices is not
> properly defined. Thus, it might be possible that big GPU has lower power
> values in abstract scale than a Little CPU. To mitigate a misbehaviour
> of the thermal control algorithm, simply not register a cooling device
> capable of working with IPA.
Ugh, this would break thermal throttling for existing devices that are
currently supported in the upstream kernel.
Wasn't the conclusion that it is the responsability of the device tree
owners to ensure that cooling devices with different scales aren't used
in the same thermal zone?
That's also what's currently specified in the power allocator
documentation:
Another important thing is the consistent scale of the power values
provided by the cooling devices. All of the cooling devices in a single
thermal zone should have power values reported either in milli-Watts
or scaled to the same 'abstract scale'.
Which was actually added by yourself:
commit 5a64f775691647c242aa40d34f3512e7b179a921
Author: Lukasz Luba <lukasz.luba@arm.com>
Date: Tue Nov 3 09:05:58 2020 +0000
PM: EM: Clarify abstract scale usage for power values in Energy Model
The Energy Model (EM) can store power values in milli-Watts or in abstract
scale. This might cause issues in the subsystems which use the EM for
estimating the device power, such as:
- mixing of different scales in a subsystem which uses multiple
(cooling) devices (e.g. thermal Intelligent Power Allocation (IPA))
- assuming that energy [milli-Joules] can be derived from the EM power
values which might not be possible since the power scale doesn't have
to be in milli-Watts
To avoid misconfiguration add the requisite documentation to the EM and
related subsystems: EAS and IPA.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It's ugly to have the abstract scales in the first place, but that's
unfortunately what we currently have for at least some cooling devices.
IMO it would be preferable to stick to catching incompliant configurations
in reviews, rather than breaking thermal throttling for existing devices
with configurations that comply with the current documentation.
next prev parent reply other threads:[~2022-02-08 1:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-07 7:30 [PATCH 0/2] Ignore Energy Model with abstract scale in IPA and DTPM Lukasz Luba
2022-02-07 7:30 ` [PATCH 1/2] thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling Lukasz Luba
2022-02-08 0:50 ` Matthias Kaehlcke [this message]
2022-02-08 9:32 ` Lukasz Luba
2022-02-08 17:25 ` Matthias Kaehlcke
2022-02-09 11:16 ` Lukasz Luba
2022-02-09 22:17 ` Matthias Kaehlcke
2022-02-16 15:35 ` Lukasz Luba
2022-02-16 17:33 ` Doug Anderson
2022-02-16 22:13 ` Matthias Kaehlcke
2022-02-16 22:43 ` Lukasz Luba
2022-02-17 0:26 ` Matthias Kaehlcke
2022-02-17 10:15 ` Daniel Lezcano
2022-02-17 9:59 ` Daniel Lezcano
2022-02-17 10:10 ` Daniel Lezcano
2022-02-17 10:47 ` Lukasz Luba
2022-02-17 11:28 ` Daniel Lezcano
2022-02-17 12:11 ` Lukasz Luba
2022-02-17 12:33 ` Daniel Lezcano
2022-02-17 12:37 ` Lukasz Luba
2022-02-17 16:46 ` Matthias Kaehlcke
2022-02-17 16:37 ` Doug Anderson
2022-02-17 17:14 ` Matthias Kaehlcke
2022-02-17 18:05 ` Lukasz Luba
2022-02-17 18:27 ` Daniel Lezcano
2022-02-16 17:21 ` Doug Anderson
2022-02-16 23:28 ` Lukasz Luba
2022-02-17 16:50 ` Doug Anderson
2022-02-17 17:58 ` Lukasz Luba
2022-02-17 18:18 ` Lukasz Luba
2022-02-22 17:05 ` Lukasz Luba
2022-02-22 18:12 ` Daniel Lezcano
2022-02-22 18:31 ` Lukasz Luba
2022-02-22 22:10 ` Daniel Lezcano
2022-02-23 9:10 ` Lukasz Luba
2022-02-07 7:30 ` [PATCH 2/2] powercap: DTPM: Check Energy Model type for power values scale Lukasz Luba
2022-02-07 10:41 ` [PATCH 0/2] Ignore Energy Model with abstract scale in IPA and DTPM Daniel Lezcano
2022-02-07 11:44 ` Lukasz Luba
2022-02-08 7:39 ` Daniel Lezcano
2022-02-08 9:47 ` Lukasz Luba
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=YgG+TmLrCSXX4Bvt@google.com \
--to=mka@chromium.org \
--cc=Pierre.Gondois@arm.com \
--cc=amit.kachhap@gmail.com \
--cc=amitk@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=dianders@chromium.org \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=rafael@kernel.org \
--cc=rnayak@codeaurora.org \
--cc=rui.zhang@intel.com \
--cc=swboyd@chromium.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).