linux-kernel - Re: [PATCH v5 09/23] PM: EM: Use runtime modified EM for CPUs energy estimation in EAS

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: <1ccd7a20-0479-46f7-a968-57a18f0c0152@arm.com>
Date: Tue, 19 Dec 2023 08:32:19 +0000
From: Lukasz Luba <lukasz.luba@....com>
To: Xuewen Yan <xuewen.yan94@...il.com>, Qais Yousef <qyousef@...alina.io>
Cc: linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
 rafael@...nel.org, dietmar.eggemann@....com, rui.zhang@...el.com,
 amit.kucheria@...durent.com, amit.kachhap@...il.com,
 daniel.lezcano@...aro.org, viresh.kumar@...aro.org, len.brown@...el.com,
 pavel@....cz, mhiramat@...nel.org, wvw@...gle.com
Subject: Re: [PATCH v5 09/23] PM: EM: Use runtime modified EM for CPUs energy
 estimation in EAS

Hi Qais and Xuewen,

On 12/19/23 04:03, Xuewen Yan wrote:
> On Mon, Dec 18, 2023 at 1:59 AM Qais Yousef <qyousef@...alina.io> wrote:
>>
>> On 11/29/23 11:08, Lukasz Luba wrote:
>>> The new Energy Model (EM) supports runtime modification of the performance
>>> state table to better model the power used by the SoC. Use this new
>>> feature to improve energy estimation and therefore task placement in
>>> Energy Aware Scheduler (EAS).
>>
>> nit: you moved the code to use the new runtime em table instead of the one
>> parsed at boot.
>>
>>>
>>> Signed-off-by: Lukasz Luba <lukasz.luba@....com>
>>> ---
>>>   include/linux/energy_model.h | 16 ++++++++++++----
>>>   1 file changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
>>> index 1e618e431cac..94a77a813724 100644
>>> --- a/include/linux/energy_model.h
>>> +++ b/include/linux/energy_model.h
>>> @@ -238,6 +238,7 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
>>>                                unsigned long max_util, unsigned long sum_util,
>>>                                unsigned long allowed_cpu_cap)
>>>   {
>>> +     struct em_perf_table *runtime_table;
>>>        unsigned long freq, scale_cpu;
>>>        struct em_perf_state *ps;
>>>        int cpu, i;
>>> @@ -255,7 +256,14 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
>>>         */
>>>        cpu = cpumask_first(to_cpumask(pd->cpus));
>>>        scale_cpu = arch_scale_cpu_capacity(cpu);
>>> -     ps = &pd->table[pd->nr_perf_states - 1];
>>> +
>>> +     /*
>>> +      * No rcu_read_lock() since it's already called by task scheduler.
>>> +      * The runtime_table is always there for CPUs, so we don't check.
>>> +      */
>>
>> WARN_ON(rcu_read_lock_held()) instead?
> 
> I agree, or SCHED_WARN_ON(!rcu_read_lock_held()) ?

I disagree here. This is a sched function in hot path and as comment
says:

-----------------------
  * This function must be used only for CPU devices. There is no validation,
  * i.e. if the EM is a CPU type and has cpumask allocated. It is called 
from
  * the scheduler code quite frequently and that is why there is not checks.
-----------------------

We don't have to put the checks or warnings everywhere in the kernel
functions. Especially hot one like this one.

As you might not notice, we don't even check if the pd->cpus is not NULL

Regards,
Lukasz