linux-kernel - Re: [PATCH 1/2] thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3d1719ca-d4a4-f904-e284-b857414669ba@linaro.org>
Date:   Tue, 22 Feb 2022 19:12:35 +0100
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Lukasz Luba <lukasz.luba@....com>
Cc:     amit.kachhap@...il.com, viresh.kumar@...aro.org, rafael@...nel.org,
        amitk@...nel.org, rui.zhang@...el.com, dietmar.eggemann@....com,
        Pierre.Gondois@....com, Matthias Kaehlcke <mka@...omium.org>,
        Doug Anderson <dianders@...omium.org>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] thermal: cooling: Check Energy Model type in
 cpufreq_cooling and devfreq_cooling


Hi Lukasz,

I don't think it makes sense to remove the support of the energy model 
if the units are abstracts.

IIUC, regarding your previous answer, we don't really know what will do 
the SoC vendor with these numbers and likely they will provide 
consistent abstract values which won't prevent a correct behavior.

What would be the benefit of giving inconsistent abstract values which 
will be unusable except of giving a broken energy model?

Your proposed changes would be acceptable if the energy model has a 
broken flag IMO

On 22/02/2022 18:05, Lukasz Luba wrote:
> Hi Daniel,
> 
> gentle ping
> 
> On 2/17/22 18:18, Lukasz Luba wrote:
>> Hi Daniel,
>>
>>
>> On 2/7/22 7:30 AM, 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.
>>>
>>> Signed-off-by: Lukasz Luba <lukasz.luba@....com>
>>> ---
>>>   drivers/thermal/cpufreq_cooling.c |  2 +-
>>>   drivers/thermal/devfreq_cooling.c | 16 +++++++++++++---
>>>   2 files changed, 14 insertions(+), 4 deletions(-)
>>
>> The discussion in below this patch went slightly off-topic but it was
>> valuable. It clarified also there are no broken platforms with this
>> change.
>>
>> Could you take the patch into the thermal tree, please?
>>
>> Regards,
>> Lukasz


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog