From: Lukasz Luba <lukasz.luba@arm.com>
To: Qais Yousef <qyousef@layalina.io>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
rafael@kernel.org, dietmar.eggemann@arm.com, rui.zhang@intel.com,
amit.kucheria@verdurent.com, amit.kachhap@gmail.com,
daniel.lezcano@linaro.org, viresh.kumar@linaro.org,
len.brown@intel.com, pavel@ucw.cz, mhiramat@kernel.org,
wvw@google.com
Subject: Re: [PATCH v5 14/23] PM: EM: Support late CPUs booting and capacity adjustment
Date: Tue, 2 Jan 2024 11:39:23 +0000 [thread overview]
Message-ID: <47c72c07-aafe-4f94-864b-53f9e45857db@arm.com> (raw)
In-Reply-To: <20231217180038.vcyaaoni3nvmlf6f@airbuntu>
On 12/17/23 18:00, Qais Yousef wrote:
> On 11/29/23 11:08, Lukasz Luba wrote:
>> The patch adds needed infrastructure to handle the late CPUs boot, which
>> might change the previous CPUs capacity values. With this changes the new
>> CPUs which try to register EM will trigger the needed re-calculations for
>> other CPUs EMs. Thanks to that the em_per_state::performance values will
>> be aligned with the CPU capacity information after all CPUs finish the
>> boot and EM registrations.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>> kernel/power/energy_model.c | 121 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 121 insertions(+)
>>
>> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
>> index b5016afe6a19..d3fa5a77de80 100644
>> --- a/kernel/power/energy_model.c
>> +++ b/kernel/power/energy_model.c
>> @@ -25,6 +25,9 @@ static DEFINE_MUTEX(em_pd_mutex);
>>
>> static void em_cpufreq_update_efficiencies(struct device *dev,
>> struct em_perf_state *table);
>> +static void em_check_capacity_update(void);
>> +static void em_update_workfn(struct work_struct *work);
>> +static DECLARE_DELAYED_WORK(em_update_work, em_update_workfn);
>>
>> static bool _is_cpu_device(struct device *dev)
>> {
>> @@ -596,6 +599,10 @@ int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
>>
>> unlock:
>> mutex_unlock(&em_pd_mutex);
>> +
>> + if (_is_cpu_device(dev))
>> + em_check_capacity_update();
>> +
>> return ret;
>> }
>> EXPORT_SYMBOL_GPL(em_dev_register_perf_domain);
>> @@ -631,3 +638,117 @@ void em_dev_unregister_perf_domain(struct device *dev)
>> mutex_unlock(&em_pd_mutex);
>> }
>> EXPORT_SYMBOL_GPL(em_dev_unregister_perf_domain);
>> +
>> +/*
>> + * Adjustment of CPU performance values after boot, when all CPUs capacites
>> + * are correctly calculated.
>> + */
>> +static void em_adjust_new_capacity(struct device *dev,
>> + struct em_perf_domain *pd,
>> + u64 max_cap)
>> +{
>> + struct em_perf_table __rcu *runtime_table;
>> + struct em_perf_state *table, *new_table;
>> + int ret, table_size;
>> +
>> + runtime_table = em_allocate_table(pd);
>> + if (!runtime_table) {
>> + dev_warn(dev, "EM: allocation failed\n");
>> + return;
>> + }
>> +
>> + new_table = runtime_table->state;
>> +
>> + table = em_get_table(pd);
>> + /* Initialize data based on older runtime table */
>> + table_size = sizeof(struct em_perf_state) * pd->nr_perf_states;
>> + memcpy(new_table, table, table_size);
>> +
>> + em_put_table();
>> +
>> + em_init_performance(dev, pd, new_table, pd->nr_perf_states);
>> + ret = em_compute_costs(dev, new_table, NULL, pd->nr_perf_states,
>> + pd->flags);
>> + if (ret) {
>> + em_free_table(runtime_table);
>> + return;
>> + }
>> +
>> + ret = em_dev_update_perf_domain(dev, runtime_table);
>> + if (ret)
>> + dev_warn(dev, "EM: update failed %d\n", ret);
>> +
>> + /*
>> + * This is one-time-update, so give up the ownership in this updater.
>> + * The EM fwk will keep the reference and free the memory when needed.
>> + */
>> + em_free_table(runtime_table);
>> +}
>> +
>> +static void em_check_capacity_update(void)
>> +{
>> + cpumask_var_t cpu_done_mask;
>> + struct em_perf_state *table;
>> + struct em_perf_domain *pd;
>> + unsigned long cpu_capacity;
>> + int cpu;
>> +
>> + if (!zalloc_cpumask_var(&cpu_done_mask, GFP_KERNEL)) {
>> + pr_warn("no free memory\n");
>> + return;
>> + }
>> +
>> + /* Check if CPUs capacity has changed than update EM */
>> + for_each_possible_cpu(cpu) {
>
> Can't we instead hook into cpufreq_online/offline() to check if we need to
> do any em related update for this policy?
>
I think it would be a bit over-engineering. We know the moment when
there is a need for this check - it's when new EM is registered.
Also, for the cpu hotplug, not always the capacity would change,
which would confuse in such code. Not mentioning, that it will create
an extra everhead for that hotplug notification chain, for not good
reason.
next prev parent reply other threads:[~2024-01-02 11:38 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-29 11:08 [PATCH v5 00/23] Introduce runtime modifiable Energy Model Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 01/23] PM: EM: Add missing newline for the message log Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 02/23] PM: EM: Refactor em_cpufreq_update_efficiencies() arguments Lukasz Luba
2023-12-17 17:58 ` Qais Yousef
2023-12-19 10:30 ` Lukasz Luba
2023-12-28 16:59 ` Qais Yousef
2024-01-02 9:40 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 03/23] PM: EM: Find first CPU active while updating OPP efficiency Lukasz Luba
2023-12-17 17:58 ` Qais Yousef
2023-12-19 10:53 ` Lukasz Luba
2023-12-28 17:13 ` Qais Yousef
2024-01-02 9:42 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 04/23] PM: EM: Refactor em_pd_get_efficient_state() to be more flexible Lukasz Luba
2023-12-12 18:49 ` Dietmar Eggemann
2023-12-19 10:58 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 05/23] PM: EM: Refactor a new function em_compute_costs() Lukasz Luba
2023-12-17 17:58 ` Qais Yousef
2023-12-19 10:59 ` Lukasz Luba
2023-12-28 17:14 ` Qais Yousef
2024-01-02 9:43 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 06/23] PM: EM: Check if the get_cost() callback is present in em_compute_costs() Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 07/23] PM: EM: Refactor how the EM table is allocated and populated Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-19 13:19 ` Lukasz Luba
2023-12-17 17:59 ` Qais Yousef
2023-11-29 11:08 ` [PATCH v5 08/23] PM: EM: Introduce runtime modifiable table Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-19 11:33 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 09/23] PM: EM: Use runtime modified EM for CPUs energy estimation in EAS Lukasz Luba
2023-12-17 17:59 ` Qais Yousef
2023-12-19 4:03 ` Xuewen Yan
2023-12-19 8:32 ` Lukasz Luba
2023-12-28 17:32 ` Qais Yousef
2024-01-02 11:17 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 10/23] PM: EM: Add API for memory allocations for new tables Lukasz Luba
2023-12-17 17:59 ` Qais Yousef
2023-12-19 8:45 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 11/23] PM: EM: Add API for updating the runtime modifiable EM Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-20 8:06 ` Lukasz Luba
2024-01-04 15:45 ` Dietmar Eggemann
2024-01-04 16:55 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 12/23] PM: EM: Add helpers to read under RCU lock the EM table Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 13/23] PM: EM: Add performance field to struct em_perf_state Lukasz Luba
2023-12-17 18:00 ` Qais Yousef
2023-12-20 8:21 ` Lukasz Luba
2023-12-28 17:45 ` Qais Yousef
2023-11-29 11:08 ` [PATCH v5 14/23] PM: EM: Support late CPUs booting and capacity adjustment Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-20 8:23 ` Lukasz Luba
2023-12-17 18:00 ` Qais Yousef
2024-01-02 11:39 ` Lukasz Luba [this message]
2023-11-29 11:08 ` [PATCH v5 15/23] PM: EM: Optimize em_cpu_energy() and remove division Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-20 8:42 ` Lukasz Luba
2024-01-04 16:30 ` Dietmar Eggemann
2024-01-04 16:56 ` Lukasz Luba
2023-12-28 18:06 ` Qais Yousef
2024-01-02 11:47 ` Lukasz Luba
2024-01-04 19:23 ` Qais Yousef
2024-01-10 13:53 ` Lukasz Luba
2024-01-15 12:21 ` Qais Yousef
2024-01-15 12:36 ` Lukasz Luba
2024-01-16 13:10 ` Qais Yousef
2024-01-16 15:34 ` Lukasz Luba
2024-01-16 19:33 ` Qais Yousef
2023-11-29 11:08 ` [PATCH v5 16/23] powercap/dtpm_cpu: Use new Energy Model interface to get table Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 17/23] powercap/dtpm_devfreq: " Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 18/23] drivers/thermal/cpufreq_cooling: Use new Energy Model interface Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 19/23] drivers/thermal/devfreq_cooling: " Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 20/23] PM: EM: Change debugfs configuration to use runtime EM table data Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 21/23] PM: EM: Remove old table Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 22/23] PM: EM: Add em_dev_compute_costs() as API for device drivers Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-17 18:03 ` Qais Yousef
2023-12-18 11:56 ` Lukasz Luba
2023-12-20 11:14 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 23/23] Documentation: EM: Update with runtime modification design Lukasz Luba
2023-12-12 18:51 ` Dietmar Eggemann
2023-12-19 9:35 ` Lukasz Luba
2023-12-19 4:42 ` Xuewen Yan
2023-12-19 8:47 ` Lukasz Luba
2023-12-19 6:22 ` Xuewen Yan
2023-12-19 9:32 ` Lukasz Luba
2023-12-20 2:08 ` Xuewen Yan
2023-12-20 7:57 ` Lukasz Luba
2023-12-12 18:48 ` [PATCH v5 00/23] Introduce runtime modifiable Energy Model Dietmar Eggemann
2023-12-13 9:23 ` Lukasz Luba
2023-12-13 11:34 ` Dietmar Eggemann
2023-12-13 11:45 ` Rafael J. Wysocki
2023-12-13 12:20 ` Lukasz Luba
2023-12-12 18:49 ` Rafael J. Wysocki
2023-12-13 9:32 ` Lukasz Luba
2023-12-13 13:40 ` Hongyan Xia
2023-12-13 13:16 ` Lukasz Luba
2023-12-17 18:22 ` Qais Yousef
2023-12-19 10:22 ` Lukasz Luba
2023-12-28 18:41 ` Qais Yousef
2024-01-02 12:12 ` 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=47c72c07-aafe-4f94-864b-53f9e45857db@arm.com \
--to=lukasz.luba@arm.com \
--cc=amit.kachhap@gmail.com \
--cc=amit.kucheria@verdurent.com \
--cc=daniel.lezcano@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=pavel@ucw.cz \
--cc=qyousef@layalina.io \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
--cc=viresh.kumar@linaro.org \
--cc=wvw@google.com \
/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®