From: Lukasz Luba <lukasz.luba@arm.com>
To: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
daniel.lezcano@linaro.org, amitk@kernel.org,
Dietmar.Eggemann@arm.com
Subject: Re: [PATCH 2/2] thermal: power allocator: estimate sustainable power only once
Date: Thu, 8 Oct 2020 13:34:40 +0100 [thread overview]
Message-ID: <d57cc0aa-01e4-e3b2-c591-be7e54f95780@arm.com> (raw)
In-Reply-To: <20201008101434.GA23491@arm.com>
Hi Ionela,
On 10/8/20 11:14 AM, Ionela Voinescu wrote:
> Hi Lukasz,
>
> On Friday 02 Oct 2020 at 13:24:16 (+0100), Lukasz Luba wrote:
>> The sustainable power value might come from the Device Tree or can be
>> estimated in run time. There is no need to estimate every time when the
>> governor is called and temperature is high. Instead, store the estimated
>> value and make it available via standard sysfs interface so it can be
>> checked from the user-space.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>> drivers/thermal/gov_power_allocator.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/thermal/gov_power_allocator.c b/drivers/thermal/gov_power_allocator.c
>> index f69fafe486a5..dd59085f38f5 100644
>> --- a/drivers/thermal/gov_power_allocator.c
>> +++ b/drivers/thermal/gov_power_allocator.c
>> @@ -204,6 +204,8 @@ static u32 pid_controller(struct thermal_zone_device *tz,
>> estimate_pid_constants(tz, sustainable_power,
>> params->trip_switch_on, control_temp,
>> true);
>> + /* Do the estimation only once and make available in sysfs */
>> + tz->tzp->sustainable_power = sustainable_power;
>
> After looking over the code, it does seems mostly useless to do the
> estimation every time the controller kicks in.
>
> But I have two comments in this regard:
>
> - The estimation is dependent on the temperature we control for which
> can be changed from sysfs. While I don't see that as a big worry,
> (sustainable power is an estimation anyway), it might be worth a
> more detailed comment on why we don't expect this to be a problem,
> or what we expect the consequences of computing sustainable power
> only once could be.
The problem is that we don't expose the estimated value in the sysfs.
This is the case when there was no DT entry with 'sustainable-power'.
If someone is going to write the values via sysfs, we assume he/she
knows the consequences and also what other values to write and where,
to make it working optimally.
>
> - In the function comment for estimate_pid_constants() there is a
> mention of sustainable power:
> """
> * Sustainable power is provided in case it was estimated. The
> * estimated sustainable_power should not be stored in the
> * thermal_zone_parameters so it has to be passed explicitly to this
> * function.
> """
Good catch, that comment left. I will remove it.
> If we are going to compute the sustainable power estimation only once,
> this comment should be removed, the estimated value should be added to
> the trip point parameters before estimate_pid_constants(), and the
> sustainable_power argument should be removed.
> Otherwise we end up with conflicting information in the code.
We can also call estimate_sustainable_power() inside the
estimate_pid_constants() if sust. power was 0, then set the
tz->tzp->sustainable_power = sustainable_power
Thank you for your comments.
Regards,
Lukasz
>
> Regards,
> Ionela.
>
prev parent reply other threads:[~2020-10-08 12:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 12:24 [PATCH 0/2] Improve the estimations in Intelligent Power Allocation Lukasz Luba
2020-10-02 12:24 ` [PATCH 1/2] thermal: power allocator: change the 'k_i' coefficient estimation Lukasz Luba
2020-10-13 10:21 ` Daniel Lezcano
2020-10-13 10:59 ` Lukasz Luba
2020-10-13 11:22 ` Daniel Lezcano
2020-10-13 12:04 ` Lukasz Luba
2020-10-13 15:56 ` Daniel Lezcano
2020-10-02 12:24 ` [PATCH 2/2] thermal: power allocator: estimate sustainable power only once Lukasz Luba
2020-10-08 10:14 ` Ionela Voinescu
2020-10-08 12:34 ` Lukasz Luba [this message]
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=d57cc0aa-01e4-e3b2-c591-be7e54f95780@arm.com \
--to=lukasz.luba@arm.com \
--cc=Dietmar.Eggemann@arm.com \
--cc=amitk@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=ionela.voinescu@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.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).