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:   Mon, 15 May 2023 10:47:42 +0200
From:   Pierre Gondois <pierre.gondois@....com>
To:     Lukasz Luba <lukasz.luba@....com>
Cc:     dietmar.eggemann@....com, rui.zhang@...el.com, rafael@...nel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        amit.kucheria@...durent.com, amit.kachhap@...il.com,
        daniel.lezcano@...aro.org, viresh.kumar@...aro.org,
        len.brown@...el.com, pavel@....cz, ionela.voinescu@....com,
        rostedt@...dmis.org, mhiramat@...nel.org
Subject: Re: [PATCH 02/17] PM: EM: Find first CPU online while updating OPP
 efficiency

Hi Lukasz,

On 5/10/23 09:08, Lukasz Luba wrote:
> 
> 
> On 4/11/23 16:40, Pierre Gondois wrote:
>> Hello Lukasz,
>>
>> On 3/14/23 11:33, Lukasz Luba wrote:
>>> The Energy Model might be updated at runtime and the energy efficiency
>>> for each OPP may change. Thus, there is a need to update also the
>>> cpufreq framework and make it aligned to the new values. In order to
>>> do that, use a first online CPU from the Performance Domain.
>>>
>>> Signed-off-by: Lukasz Luba <lukasz.luba@....com>
>>> ---
>>>    kernel/power/energy_model.c | 11 +++++++++--
>>>    1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
>>> index 265d51a948d4..3d8d1fad00ac 100644
>>> --- a/kernel/power/energy_model.c
>>> +++ b/kernel/power/energy_model.c
>>> @@ -246,12 +246,19 @@ em_cpufreq_update_efficiencies(struct device
>>> *dev, struct em_perf_state *table)
>>>        struct em_perf_domain *pd = dev->em_pd;
>>>        struct cpufreq_policy *policy;
>>>        int found = 0;
>>> -    int i;
>>> +    int i, cpu;
>>>        if (!_is_cpu_device(dev) || !pd)
>>>            return;
>>
>> Since dev is a CPU, I think it shouldn be possible to get the cpu id via
>> 'dev->id'.
>> If so the code below should not be necessary anymore.
> 
> When you look at the code it does two things.
> It tries to get the CPU id - this might be similar to what you
> have proposed with the 'dev->id' but it's also looking at CPUs
> which are 'active'. The 'dev' that we have might come from
> some place, e.g. thermal cooling, which had a first CPU in
> the domain stored somewhere. That CPU might be sometimes
> not active, but the rest of the CPUs in the domain might be
> running. We have to find an active CPU id and then we get the
> 'policy'.

It seems that all the call chains look like (the first argument is important):
em_dev_register_perf_domain(get_cpu_device(policy->cpu), ...)
\-em_cpufreq_update_efficiencies()

Whenever a CPU is unplugged in cpufreq, a new CPU is put in charge of
the policy (cf. __cpufreq_offline(), policy->cpu is updated). So the
'dev' that em_cpufreq_update_efficiencies() receives should be an active
device, with no need to check that the device is active.

This would be just an optimization, the present code seems also valid
to me.

Another NIT, I saw a cpumask_copy() in energy_model.c, but no
free_cpumask_var(). This could be done separately from this patchset
(if relevant).

Regards,
Pierre


> 
>>
>>> -    policy = cpufreq_cpu_get(cpumask_first(em_span_cpus(pd)));
>>> +    /* Try to get a CPU which is online and in this PD */
>>> +    cpu = cpumask_first_and(em_span_cpus(pd), cpu_active_mask);
>>> +    if (cpu >= nr_cpu_ids) {
>>> +        dev_warn(dev, "EM: No online CPU for CPUFreq policy\n");
>>> +        return;
>>> +    }
>>> +
>>> +    policy = cpufreq_cpu_get(cpu);
>>>        if (!policy) {
>>>            dev_warn(dev, "EM: Access to CPUFreq policy failed");
>>>            return;
>>
>> Regards,
>> Pierre

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ