From: Lukasz Luba <lukasz.luba@arm.com>
To: Matthias Kaehlcke <mka@chromium.org>,
Doug Anderson <dianders@chromium.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
amit daniel kachhap <amit.kachhap@gmail.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Amit Kucheria <amitk@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Pierre.Gondois@arm.com, Stephen Boyd <swboyd@chromium.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
jorcrous@amazon.com, Rob Clark <robdclark@chromium.org>
Subject: Re: [PATCH 1/2] thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling
Date: Thu, 17 Feb 2022 18:05:14 +0000 [thread overview]
Message-ID: <7b51e2a9-99c3-f33c-690a-fa72692da612@arm.com> (raw)
In-Reply-To: <Yg6CaT9iQGXXi7s2@google.com>
On 2/17/22 5:14 PM, Matthias Kaehlcke wrote:
> On Thu, Feb 17, 2022 at 08:37:39AM -0800, Doug Anderson wrote:
>> Hi,
>>
>> On Thu, Feb 17, 2022 at 2:47 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>>
>>> Hi Daniel,
>>>
>>> On 2/17/22 10:10 AM, Daniel Lezcano wrote:
>>>> On 16/02/2022 18:33, Doug Anderson wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Feb 16, 2022 at 7:35 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>>>>>
>>>>>> Hi Matthias,
>>>>>>
>>>>>> On 2/9/22 10:17 PM, Matthias Kaehlcke wrote:
>>>>>>> On Wed, Feb 09, 2022 at 11:16:36AM +0000, Lukasz Luba wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/8/22 5:25 PM, Matthias Kaehlcke wrote:
>>>>>>>>> On Tue, Feb 08, 2022 at 09:32:28AM +0000, Lukasz Luba wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>>>>>> Could you point me to those devices please?
>>>>>>>>>
>>>>>>>>> arch/arm64/boot/dts/qcom/sc7180-trogdor-*
>>>>>>>>>
>>>>>>>>> Though as per above they shouldn't be impacted by your change,
>>>>>>>>> since the
>>>>>>>>> CPUs always pretend to use milli-Watts.
>>>>>>>>>
>>>>>>>>> [skipped some questions/answers since sc7180 isn't actually
>>>>>>>>> impacted by
>>>>>>>>> the change]
>>>>>>>>
>>>>>>>> Thank you Matthias. I will investigate your setup to get better
>>>>>>>> understanding.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>
>>>>>> I've checked those DT files and related code.
>>>>>> As you already said, this patch is safe for them.
>>>>>> So we can apply it IMO.
>>>>>>
>>>>>>
>>>>>> -------------Off-topic------------------
>>>>>> Not in $subject comments:
>>>>>>
>>>>>> AFAICS based on two files which define thermal zones:
>>>>>> sc7180-trogdor-homestar.dtsi
>>>>>> sc7180-trogdor-coachz.dtsi
>>>>>>
>>>>>> only the 'big' cores are used as cooling devices in the
>>>>>> 'skin_temp_thermal' - the CPU6 and CPU7.
>>>>>>
>>>>>> I assume you don't want to model at all the power usage
>>>>>> from the Little cluster (which is quite big: 6 CPUs), do you?
>>>>>> I can see that the Little CPUs have small dyn-power-coeff
>>>>>> ~30% of the big and lower max freq, but still might be worth
>>>>>> to add them to IPA. You might give them more 'weight', to
>>>>>> make sure they receive more power during power split.
>>>>>>
>>>>>> You also don't have GPU cooling device in that thermal zone.
>>>>>> Based on my experience if your GPU is a power hungry one,
>>>>>> e.g. 2-4Watts, you might get better results when you model
>>>>>> this 'hot' device (which impacts your temp sensor reported value).
>>>>>
>>>>> I think the two boards you point at (homestar and coachz) are just the
>>>>> two that override the default defined in the SoC dtsi file. If you
>>>>> look in sc7180.dtsi you'll see 'gpuss1-thermal' which has a cooling
>>>>> map. You can also see the cooling maps for the littles.
>>>>>
>>>>> I guess we don't have a `dynamic-power-coefficient` for the GPU,
>>>>> though? Seems like we should, but I haven't dug through all the code
>>>>> here...
>>>>
>>>> The dynamic-power-coefficient is available for OPPs which includes
>>>> CPUfreq and devfreq. As the GPU is managed by devfreq, setting the
>>>> dynamic-power-coefficient makes the energy model available for it.
>>>>
>>>> However, the OPPs must define the frequency and the voltage. That is the
>>>> case for most platforms except on QCom platform.
>>>>
>>>> That may not be specified as it uses a frequency index and the hardware
>>>> does the voltage change in our back. The QCom cpufreq backend get the
>>>> voltage table from a register (or whatever) and completes the voltage
>>>> values for the OPPs, thus adding the information which is missing in the
>>>> device tree. The energy model can then initializes itself and allows the
>>>> usage of the Energy Aware Scheduler.
>>>>
>>>> However this piece of code is missing for the GPU part.
>>>>
>>>
>>> Thank you for joining the discussion. I don't know about that Qcom
>>> GPU voltage information is missing.
>>>
>>> If the voltage is not available (only the frequencies), there is
>>> another way. There is an 'advanced' EM which uses registration function:
>>> em_dev_register_perf_domain(). It uses a local driver callback to get
>>> power for each found frequency. It has benefit because there is no
>>> restriction to 'fit' into the math formula, instead just avg power
>>> values can be feed into EM. It's called 'advanced' EM [1].
>>
>> It seems like there _should_ be a way to get the voltage out for GPU
>> operating points, like is done with cpufreq in
>> qcom_cpufreq_hw_read_lut(), but it might need someone with Qualcomm
>> documentation to help with it. Maybe Rajendra would be able to help?
>> Adding Jordon and Rob to this conversation in case they're aware of
>> anything.
>>
>> As you said, we could just list a power for each frequency, though.
>>
>> I'm actually not sure which one would be more accurate across a range
>> of devices with different "corners": specifying a dynamic power
>> coefficient used for all "corners" and then using the actual voltage
>> and doing the math, or specifying a power number for each frequency
>> and ignoring the actual voltage used. In any case we're trying to get
>> ballpark numbers and not every device will be exactly the same, so
>> probably it doesn't matter that much.
>>
>>
>>> Now we hit (again) the DT & EM issue (it's an old one, IIRC Morten
>>> was proposing from ~2014 this upstream, but EAS wasn't merged back
>>> then):
>>> where to store these power-freq values, which are then used by the
>>> callback. We have the 'dynamic-power-coefficient' in DT, but
>>> it has limitations. It would be good to have this simple array
>>> attached to the GPU/CPU node. IMHO it meet the requirement of DT,
>>> it describes the HW (it would have HZ and Watts values).
>>>
>>> Doug, Matthias could you have a look at that function and its
>>> usage, please [1]?
>>> If you guys would support me in this, I would start, with an RFC
>>> proposal, a discussion on LKML.
>>>
>>> [1]
>>> https://elixir.bootlin.com/linux/v5.17-rc4/source/Documentation/power/energy-model.rst#L87
>>
>> Matthias: I think you've spent more time on the thermal stuff than me
>> so I'll assume you'll follow-up here. If not then please yell!
>>
>> Ideally, though, someone from Qualcomm would jump in an own this.
>> Basically it allows more intelligently throttling the GPU and CPU
>> together in tandem instead of treating them separately IIUC, right?
>
> Yes, I think for the em_dev_register_perf_domain() route support from
> Qualcomm would be needed since "Drivers must provide a callback
> function returning <frequency, power> tuples for each performance
> state. ".
>
Not necessarily. It might be done 'generically' by fwk.
There are other benefits of this 'energy-model' entry in the DT.
I'll list them in the cover letter. Let me send an RFC, so we could
discuss there.
Thanks guys!
Regards,
Lukasz
next prev parent reply other threads:[~2022-02-17 18:05 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
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 [this message]
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=7b51e2a9-99c3-f33c-690a-fa72692da612@arm.com \
--to=lukasz.luba@arm.com \
--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=jorcrous@amazon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mka@chromium.org \
--cc=rafael@kernel.org \
--cc=rnayak@codeaurora.org \
--cc=robdclark@chromium.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).