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]
Date:   Tue, 8 Feb 2022 08:39:03 +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, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH 0/2] Ignore Energy Model with abstract scale in IPA and
 DTPM

On 07/02/2022 12:44, Lukasz Luba wrote:
> 
> 
> On 2/7/22 10:41 AM, Daniel Lezcano wrote:
>> On 07/02/2022 08:30, Lukasz Luba wrote:
>>> Hi all,
>>>
>>> The Energy Model supports abstract scale power values. This might cause
>>> issues for some mechanisms like thermal governor IPA or DTPM, which
>>> expect that all devices provide sane power values. This patch set 
>>> prevents
>>> from registering such devices for IPA and DTPM.
>>
>>
>> Does it mean for example big and little have both 0-100 ?
>>
>>
> 
> Unfortunately, these can be any numbers. I hope at least the CPUs
> Big and Little power have sense: Little power is not higher
> than Big power. The purpose of EM is to enable EAS, so this power
> relation between Big and Little should have sense. Someone
> who is not willing to or cannot expose real power values, still
> wants the EAS to operate (my assumption and hope). The SCMI FW can
> provide abstract power values. It's in the SCMI spec. Thus,
> creating these abstract scale power values for big.LITTLE the right
> way should result in properly working EAS.
> 
> I can also have hope for GPU vs. Big power, but it is a weaker hope.
> The second is more tricky to distinguish even if you have a domain
> knowledge, but not the real measurements with you. The GPU power
> values is also a 'sensitive' knowledge to share. Open source guys can do
> that (after measurements), but some vendor's engineers probably can't.

So basically, we don't know, right ?

At this point the different subsystems (cpufreq cooling device and dtpm) 
disabled by these patches can deal with abstract scale values, like they 
do today with the very approximate power numbers we have defined in the DT.

Let's wait and see how the different SoC vendors implement the SCMI spec.




-- 
<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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ