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] [day] [month] [year] [list]

Message-ID: <b13ece66-a1c0-439f-efaa-689ddfa530db@arm.com>
Date:   Wed, 23 Feb 2022 09:10:35 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
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



On 2/22/22 22:10, Daniel Lezcano wrote:
> 
> Hi Lukasz,
> 
> On 22/02/2022 19:31, Lukasz Luba wrote:
>>
>>
>> On 2/22/22 18:12, Daniel Lezcano wrote:
>>>
>>> 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?
>>
>> The power values in the EM which has abstract scale, would make sense 
>> to EAS, but not for IPA or DTPM. Those platforms which want to enable 
>> EAS,
>> but don't need IPA, would register such '<a_good_name_here>' EM.
> 
> Sorry, but I don't understand why DTPM can not deal with abstract values?

They will be totally meaningless/bogus.

> 
> 
>>> Your proposed changes would be acceptable if the energy model has a 
>>> broken flag IMO
>>
>> That is doable. I can add that flag, so we can call it 'artificial' EM
>> (when this new flag is set).
> 
> It is too soon IMO, I would like to see the numbers first so we can take 
> an enlighten decision. Right now, it is unclear what the numbers will be.

We are going to add new support from our roadmap for platforms which
don't have this power information but are going to use EAS.

I'm going to send some patches soon which create that support. Pierre
is going to send the platform code. I want to make sure that this
platform won't register power actors for IPA. Other thermal governors
will work, since they don't use EM for making a decision.