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: <fa2bac05-1992-9166-0b5f-2477af39bb55@arm.com>
Date:   Tue, 6 Jul 2021 20:51:00 +0100
From:   Lukasz Luba <lukasz.luba@....com>
To:     Dietmar Eggemann <dietmar.eggemann@....com>,
        linux-kernel@...r.kernel.org
Cc:     Chris.Redpath@....com, morten.rasmussen@....com,
        qperret@...gle.com, linux-pm@...r.kernel.org, peterz@...radead.org,
        rjw@...ysocki.net, viresh.kumar@...aro.org,
        vincent.guittot@...aro.org, mingo@...hat.com,
        juri.lelli@...hat.com, rostedt@...dmis.org, segall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, CCj.Yeh@...iatek.com
Subject: Re: [PATCH 3/3] PM: EM: Increase energy calculation precision



On 7/5/21 1:45 PM, Dietmar Eggemann wrote:
> On 25/06/2021 17:26, Lukasz Luba wrote:
>> The Energy Model (EM) provides useful information about device power in
>> each performance state to other subsystems like: Energy Aware Scheduler
>> (EAS). The energy calculation in EAS does arithmetic operation based on
>> the EM em_cpu_energy(). Current implementation of that function uses
>> em_perf_state::cost as a pre-computed cost coefficient equal to:
>> cost = power * max_frequency / frequency.
>> The 'power' is expressed in milli-Watts (or in abstract scale).
>>
>> There are corner cases then the EAS energy calculation for two Performance
>              ^^^^^^^^^^^^
> 
> Again, an easy to understand example to describe in which situation this
> change would bring a benefit would help.
> 
>> Domains (PDs) return the same value, e.g. 10mW. The EAS compares these
>> values to choose smaller one. It might happen that this values are equal
>> due to rounding error. In such scenario, we need better precision, e.g.
>> 10000 times better. To provide this possibility increase the precision on
>> the em_perf_state::cost.
>>
>> This patch allows to avoid the rounding to milli-Watt errors, which might
>> occur in EAS energy estimation for each Performance Domains (PD). The
>> rounding error is common for small tasks which have small utilization
>> values.
> 
> What's the influence of the CPU utilization 'cpu_util_next()' here?
> 
> compute_energy()
>      em_cpu_energy()
>              return ps->cost * sum_util / scale_cpu
>                                ^^^^^^^^

This is the place where the rounding error triggers. If sum_util is
small and scale_cpu is e.g. 1024, then we have a small fraction here.
It depends on the EM 'cost', but for most platforms we have small
power and cost values, so we suffer this rounding.
The example that I gave in my response in patch 2/3 shows this.

>> The rest of the EM code doesn't change, em_perf_state::power is still
>> expressed in milli-Watts (or in abstract scale). Thus, all existing
>> platforms don't have to change their reported power. The same applies to
> 
> Not only existing platforms since there are no changes. So why
> highlighting `existing` here.?

I just wanted to be clear that it doesn't affect existing platforms
at all. We don't require to report power in better resolution e.g.
micro-Watts.
Also, the clients in the kernel won't be affected, since they use
EM 'power' filed, not 'cost'.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ