All of lore.kernel.org
 help / color / mirror / Atom feed
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.
> 

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.