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
Subject: Re: [PATCH v2 1/1] PM: EM: Add min/max available performance state limits
Date: Wed, 30 Oct 2024 11:50:57 +0000 [thread overview]
Message-ID: <96e694e3-2a65-4f39-ad35-3d1e1459102f@arm.com> (raw)
In-Reply-To: <CAJZ5v0jOYw6md9tnb1d=pQ_u06=rSiZ6FAEk1iaN47TO0w+XZQ@mail.gmail.com>
On 10/30/24 11:40, Rafael J. Wysocki wrote:
> On Tue, Oct 29, 2024 at 10:43 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>> On some devices there are HW dependencies for shared frequency and voltage
>> between devices. It will impact Energy Aware Scheduler (EAS) decision,
>> where CPUs share the voltage & frequency domain with other CPUs or devices
>> e.g.
>> - Mid CPUs + Big CPU
>> - Little CPU + L3 cache in DSU
>> - some other device + Little CPUs
>>
>> Detailed explanation of one example:
>> When the L3 cache frequency is increased, the affected Little CPUs might
>> run at higher voltage and frequency. That higher voltage causes higher CPU
>> power and thus more energy is used for running the tasks. This is
>> important for background running tasks, which try to run on energy
>> efficient CPUs.
>>
>> Therefore, add performance state limits which are applied for the device
>> (in this case CPU). This is important on SoCs with HW dependencies
>> mentioned above so that the Energy Aware Scheduler (EAS) does not use
>> performance states outside the valid min-max range for energy calculation.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>> include/linux/energy_model.h | 24 ++++++++++++++---
>> kernel/power/energy_model.c | 52 ++++++++++++++++++++++++++++++++++++
>> 2 files changed, 72 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
>> index 1ff52020cf757..e83bf230e18d1 100644
>> --- a/include/linux/energy_model.h
>> +++ b/include/linux/energy_model.h
>> @@ -55,6 +55,8 @@ struct em_perf_table {
>> * struct em_perf_domain - Performance domain
>> * @em_table: Pointer to the runtime modifiable em_perf_table
>> * @nr_perf_states: Number of performance states
>> + * @min_ps: Minimum allowed Performance State index
>> + * @max_ps: Maximum allowed Performance State index
>
> Any problem with renaming these to min_perf_state and max_perf_state
> respectively?
OK, I will change those names.
>
> That would improve the code clarity quite a bit IMV.
>
[snip]
>> static inline int
>> em_pd_get_efficient_state(struct em_perf_state *table, int nr_perf_states,
>> - unsigned long max_util, unsigned long pd_flags)
>> + unsigned long max_util, unsigned long pd_flags,
>> + int min_ps, int max_ps)
>> {
>> struct em_perf_state *ps;
>> int i;
>>
>> - for (i = 0; i < nr_perf_states; i++) {
>> + for (i = min_ps; i <= max_ps; i++) {
>> ps = &table[i];
>> if (ps->performance >= max_util) {
>> if (pd_flags & EM_PERF_DOMAIN_SKIP_INEFFICIENCIES &&
>> @@ -204,7 +213,7 @@ em_pd_get_efficient_state(struct em_perf_state *table, int nr_perf_states,
>> }
>> }
>>
>> - return nr_perf_states - 1;
>> + return max_ps;
>> }
>>
>> /**
>> @@ -254,7 +263,8 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd,
>> */
>> em_table = rcu_dereference(pd->em_table);
>> i = em_pd_get_efficient_state(em_table->state, pd->nr_perf_states,
>> - max_util, pd->flags);
>> + max_util, pd->flags, pd->min_ps,
>> + pd->max_ps);
>
> Couldn't em_pd_get_efficient_state() just take pd as an argument and
> dereference it by itself?
>
> The code would be much easier to follow then.
That's possible. I will keep the em_table rcu_dereference as is, so
only the rest of arguments with 'pd->' will be taken inside
em_pd_get_efficient_state().
So the call would look like:
em_pd_get_efficient_state(em_table->state, pd, max_util);
Thanks for the review. I will send a v3.
next prev parent reply other threads:[~2024-10-30 11:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 9:43 [PATCH v2 0/1] Update Energy Model with performance limits Lukasz Luba
2024-10-29 9:43 ` [PATCH v2 1/1] PM: EM: Add min/max available performance state limits Lukasz Luba
2024-10-29 18:29 ` Rafael J. Wysocki
2024-10-30 8:48 ` Lukasz Luba
2024-10-30 10:01 ` Lukasz Luba
2024-10-30 11:23 ` Rafael J. Wysocki
2024-10-30 11:34 ` Lukasz Luba
2024-10-30 11:41 ` Rafael J. Wysocki
2024-10-30 11:40 ` Rafael J. Wysocki
2024-10-30 11:50 ` Lukasz Luba [this message]
2024-10-30 13:18 ` Rafael J. Wysocki
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=96e694e3-2a65-4f39-ad35-3d1e1459102f@arm.com \
--to=lukasz.luba@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.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