From: Pierre Gondois <pierre.gondois@arm.com>
To: Lukasz Luba <lukasz.luba@arm.com>
Cc: dietmar.eggemann@arm.com, rui.zhang@intel.com, rafael@kernel.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
amit.kucheria@verdurent.com, amit.kachhap@gmail.com,
daniel.lezcano@linaro.org, viresh.kumar@linaro.org,
len.brown@intel.com, pavel@ucw.cz, ionela.voinescu@arm.com,
rostedt@goodmis.org, mhiramat@kernel.org
Subject: Re: [PATCH 02/17] PM: EM: Find first CPU online while updating OPP efficiency
Date: Mon, 15 May 2023 10:47:42 +0200 [thread overview]
Message-ID: <9a69f5ae-86a1-5bd4-4564-e257fe64c826@arm.com> (raw)
In-Reply-To: <0cda1fc9-2e99-66a2-b833-fe5be676d815@arm.com>
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@arm.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
next prev parent reply other threads:[~2023-05-15 8:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 10:33 [PATCH 00/17] Introduce runtime modifiable Energy Model Lukasz Luba
2023-03-14 10:33 ` [PATCH 01/17] PM: EM: Refactor em_cpufreq_update_efficiencies() arguments Lukasz Luba
2023-03-27 17:16 ` Rafael J. Wysocki
2023-04-11 15:43 ` Pierre Gondois
2023-05-10 7:00 ` Lukasz Luba
2023-04-18 22:41 ` Lukasz Luba
2023-03-14 10:33 ` [PATCH 02/17] PM: EM: Find first CPU online while updating OPP efficiency Lukasz Luba
2023-04-11 15:40 ` Pierre Gondois
2023-05-10 7:08 ` Lukasz Luba
2023-05-15 8:47 ` Pierre Gondois [this message]
2023-03-14 10:33 ` [PATCH 03/17] PM: EM: Refactor em_pd_get_efficient_state() to be more flexible Lukasz Luba
2023-03-14 10:33 ` [PATCH 04/17] PM: EM: Create a new function em_compute_costs() Lukasz Luba
2023-03-14 10:33 ` [PATCH 05/17] trace: energy_model: Add trace event for EM runtime modifications Lukasz Luba
2023-04-11 15:39 ` Pierre Gondois
2023-05-10 6:59 ` Lukasz Luba
2023-03-14 10:33 ` [PATCH 06/17] PM: EM: Add update_power() callback for " Lukasz Luba
2023-03-14 10:33 ` [PATCH 07/17] PM: EM: Check if the get_cost() callback is present in em_compute_costs() Lukasz Luba
2023-03-14 10:33 ` [PATCH 08/17] PM: EM: Introduce runtime modifiable table Lukasz Luba
2023-03-14 10:33 ` [PATCH 09/17] PM: EM: Add RCU mechanism which safely cleans the old data Lukasz Luba
2023-03-14 10:33 ` [PATCH 10/17] PM: EM: Add runtime update interface to modify EM power Lukasz Luba
2023-04-11 15:40 ` Pierre Gondois
2023-05-10 6:55 ` Lukasz Luba
2023-05-15 8:48 ` Pierre Gondois
2023-03-14 10:33 ` [PATCH 11/17] PM: EM: Use runtime modified EM for CPUs energy estimation in EAS Lukasz Luba
2023-03-14 10:33 ` [PATCH 12/17] PM: EM: Add argument to get_cost() for runtime modification Lukasz Luba
2023-03-14 10:33 ` [PATCH 13/17] PM: EM: Refactor struct em_perf_domain and add default_table Lukasz Luba
2023-03-15 11:32 ` kernel test robot
2023-03-21 11:30 ` Lukasz Luba
2023-03-14 10:33 ` [PATCH 14/17] Documentation: EM: Add a new section about the design Lukasz Luba
2023-03-14 10:33 ` [PATCH 15/17] Documentation: EM: Add a runtime modifiable EM design description Lukasz Luba
2023-03-14 10:33 ` [PATCH 16/17] Documentation: EM: Add example with driver modifying the EM Lukasz Luba
2023-03-14 10:33 ` [PATCH 17/17] Documentation: EM: Describe the API of runtime modifications Lukasz Luba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a69f5ae-86a1-5bd4-4564-e257fe64c826@arm.com \
--to=pierre.gondois@arm.com \
--cc=amit.kachhap@gmail.com \
--cc=amit.kucheria@verdurent.com \
--cc=daniel.lezcano@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=ionela.voinescu@arm.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mhiramat@kernel.org \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rui.zhang@intel.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®