From: Lukasz Luba <lukasz.luba@arm.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.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,
qyousef@layalina.io, wvw@google.com
Subject: Re: [PATCH v4 09/18] PM: EM: Introduce runtime modifiable table
Date: Fri, 29 Sep 2023 10:16:05 +0100 [thread overview]
Message-ID: <e1b36a7b-0524-0559-7ae1-801bdda91e60@arm.com> (raw)
In-Reply-To: <CAJZ5v0gxjJRoZpGjs4qWy_CQbwnztgrQxHJpffdFHeEL7ikbYQ@mail.gmail.com>
On 9/26/23 20:12, Rafael J. Wysocki wrote:
> On Mon, Sep 25, 2023 at 10:11 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>> The new runtime table would be populated with a new power data to better
>> reflect the actual power. The power can vary over time e.g. due to the
>> SoC temperature change. Higher temperature can increase power values.
>> For longer running scenarios, such as game or camera, when also other
>> devices are used (e.g. GPU, ISP) the CPU power can change. The new
>> EM framework is able to addresses this issue and change the data
>> at runtime safely.
>>
>> The runtime modifiable EM data is used by the Energy Aware Scheduler (EAS)
>> for the task placement. All the other users (thermal, etc.) are still
>> using the default (basic) EM. This fact drove the design of this feature.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>> include/linux/energy_model.h | 4 +++-
>> kernel/power/energy_model.c | 12 +++++++++++-
>> 2 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
>> index 546dee90f716..740e7c25cfff 100644
>> --- a/include/linux/energy_model.h
>> +++ b/include/linux/energy_model.h
>> @@ -39,7 +39,7 @@ struct em_perf_state {
>> /**
>> * struct em_perf_table - Performance states table
>> * @state: List of performance states, in ascending order
>> - * @rcu: RCU used for safe access and destruction
>> + * @rcu: RCU used only for runtime modifiable table
>
> This still doesn't appear to be used anywhere, so why change it here?
I will try to move this later in the series.
>
>> */
>> struct em_perf_table {
>> struct em_perf_state *state;
>> @@ -49,6 +49,7 @@ struct em_perf_table {
>> /**
>> * struct em_perf_domain - Performance domain
>> * @default_table: Pointer to the default em_perf_table
>> + * @runtime_table: Pointer to the runtime modifiable em_perf_table
>
> "Pointer to em_perf_table that can be dynamically updated"
OK
>
>> * @nr_perf_states: Number of performance states
>> * @flags: See "em_perf_domain flags"
>> * @cpus: Cpumask covering the CPUs of the domain. It's here
>> @@ -64,6 +65,7 @@ struct em_perf_table {
>> */
>> struct em_perf_domain {
>> struct em_perf_table *default_table;
>> + struct em_perf_table __rcu *runtime_table;
>> int nr_perf_states;
>> unsigned long flags;
>> unsigned long cpus[];
>> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
>> index 797141638b29..5b40db38b745 100644
>> --- a/kernel/power/energy_model.c
>> +++ b/kernel/power/energy_model.c
>> @@ -251,6 +251,9 @@ static int em_create_pd(struct device *dev, int nr_states,
>> return ret;
>> }
>>
>> + /* Initialize runtime table as default table. */
>
> Redundant comment.
I'll drop it.
>
>> + rcu_assign_pointer(pd->runtime_table, default_table);
>> +
>> if (_is_cpu_device(dev))
>> for_each_cpu(cpu, cpus) {
>> cpu_dev = get_cpu_device(cpu);
>> @@ -448,6 +451,7 @@ EXPORT_SYMBOL_GPL(em_dev_register_perf_domain);
>> */
>> void em_dev_unregister_perf_domain(struct device *dev)
>> {
>> + struct em_perf_table __rcu *runtime_table;
>> struct em_perf_domain *pd;
>>
>> if (IS_ERR_OR_NULL(dev) || !dev->em_pd)
>> @@ -457,18 +461,24 @@ void em_dev_unregister_perf_domain(struct device *dev)
>> return;
>>
>> pd = dev->em_pd;
>> -
>
> Unrelated change.
ACK
>
>> /*
>> * The mutex separates all register/unregister requests and protects
>> * from potential clean-up/setup issues in the debugfs directories.
>> * The debugfs directory name is the same as device's name.
>> */
>> mutex_lock(&em_pd_mutex);
>> +
>
> Same here.
ACK
>
>> em_debug_remove_pd(dev);
>>
>> + runtime_table = pd->runtime_table;
>> +
>> + rcu_assign_pointer(pd->runtime_table, NULL);
>> + synchronize_rcu();
>
> Is it really a good idea to call this under a mutex?
This is the unregistration of the EM code path, so a thermal
driver which gets some IRQs might not be aware that the EM
is going to vanish. That's why those two code paths: update
& unregister are protected with the same lock.
This synchronize_rcu() won't be long, but makes sure
that when we free(dev->em_pd) we don't leak runtime_table.
>
>> +
>> kfree(pd->default_table->state);
>> kfree(pd->default_table);
>> kfree(dev->em_pd);
>> +
>
> Unrelated change.
ACK
>
>> dev->em_pd = NULL;
>> mutex_unlock(&em_pd_mutex);
>> }
>> --
>
> So this really adds a pointer to a table that can be dynamically
> updated to struct em_perf_domain without any users so far. It is not
> used anywhere as of this patch AFAICS, which is not what the changelog
> is saying.
Good catch. I will adjust the changlog in header and say:
'Add infrastructure and mechanisms for the new runtime table.
The runtime modifiable EM data is used by the Energy Aware Scheduler
(EAS)for the task placement. All the other users (thermal, etc.) are
still using the default (basic) EM. This fact drove the design of this
feature.'
next prev parent reply other threads:[~2023-09-29 9:15 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-25 8:11 [PATCH v4 00/18] Introduce runtime modifiable Energy Model Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 01/18] PM: EM: Add missing newline for the message log Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 02/18] PM: EM: Refactor em_cpufreq_update_efficiencies() arguments Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 03/18] PM: EM: Find first CPU online while updating OPP efficiency Lukasz Luba
2023-09-26 18:32 ` Rafael J. Wysocki
2023-09-29 8:32 ` Lukasz Luba
2023-10-23 17:06 ` Daniel Lezcano
2023-10-24 7:50 ` Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 04/18] PM: EM: Refactor em_pd_get_efficient_state() to be more flexible Lukasz Luba
2023-10-23 17:39 ` Daniel Lezcano
2023-10-24 8:09 ` Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 05/18] PM: EM: Refactor a new function em_compute_costs() Lukasz Luba
2023-09-26 18:39 ` Rafael J. Wysocki
2023-09-29 8:38 ` Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 06/18] PM: EM: Check if the get_cost() callback is present in em_compute_costs() Lukasz Luba
2023-09-26 18:46 ` Rafael J. Wysocki
2023-09-29 8:42 ` Lukasz Luba
2023-10-23 18:23 ` Daniel Lezcano
2023-10-24 8:14 ` Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 07/18] PM: EM: Refactor struct em_perf_domain and add default_table Lukasz Luba
2023-09-26 18:52 ` Rafael J. Wysocki
2023-09-29 8:45 ` Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 08/18] PM: EM: Add update_power() callback for runtime modifications Lukasz Luba
2023-09-26 18:59 ` Rafael J. Wysocki
2023-09-29 9:00 ` Lukasz Luba
2023-09-29 12:18 ` Rafael J. Wysocki
2023-09-25 8:11 ` [PATCH v4 09/18] PM: EM: Introduce runtime modifiable table Lukasz Luba
2023-09-26 19:12 ` Rafael J. Wysocki
2023-09-29 9:16 ` Lukasz Luba [this message]
2023-09-29 12:27 ` Rafael J. Wysocki
2023-10-06 8:03 ` Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 10/18] PM: EM: Add RCU mechanism which safely cleans the old data Lukasz Luba
2023-09-26 10:28 ` kernel test robot
2023-09-26 19:26 ` Rafael J. Wysocki
2023-09-29 9:36 ` Lukasz Luba
2023-09-29 12:59 ` Rafael J. Wysocki
2023-10-02 13:44 ` Lukasz Luba
2023-10-06 8:46 ` Lukasz Luba
2023-10-11 16:02 ` Wei Wang
2023-10-11 16:07 ` Rafael J. Wysocki
2023-10-12 13:16 ` Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 11/18] PM: EM: Add runtime update interface to modify EM power Lukasz Luba
2023-09-26 17:21 ` kernel test robot
2023-09-26 19:48 ` Rafael J. Wysocki
2023-09-29 10:00 ` Lukasz Luba
2023-09-29 13:18 ` Rafael J. Wysocki
2023-10-02 14:09 ` Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 12/18] PM: EM: Use runtime modified EM for CPUs energy estimation in EAS Lukasz Luba
2023-09-26 19:54 ` Rafael J. Wysocki
2023-09-29 10:10 ` Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 13/18] Documentation: EM: Update with runtime modification design Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 14/18] PM: EM: Add performance field to struct em_perf_state Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 15/18] PM: EM: Adjust performance with runtime modification callback Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 16/18] PM: EM: Support late CPUs booting and capacity adjustment Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 17/18] PM: EM: Optimize em_cpu_energy() and remove division Lukasz Luba
2023-09-25 8:11 ` [PATCH v4 18/18] Documentation: EM: Update information about performance field Lukasz Luba
2023-09-28 21:56 ` [PATCH v4 00/18] Introduce runtime modifiable Energy Model Qais Yousef
2023-10-03 8:06 ` 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=e1b36a7b-0524-0559-7ae1-801bdda91e60@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®