linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).