All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Luba <lukasz.luba@arm.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: 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,
	Pierre.Gondois@arm.com, ionela.voinescu@arm.com,
	rostedt@goodmis.org, mhiramat@kernel.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	rafael@kernel.org
Subject: Re: [PATCH v2 08/17] PM: EM: Introduce runtime modifiable table
Date: Mon, 3 Jul 2023 16:58:14 +0100	[thread overview]
Message-ID: <bcf297db-4878-84e2-842d-178b79d7abbe@arm.com> (raw)
In-Reply-To: <c4052a3d-ab24-6c20-ed07-d752098e6286@arm.com>



On 5/30/23 11:18, Dietmar Eggemann wrote:
> On 12/05/2023 11:57, Lukasz Luba wrote:
>> This patch introduces the new feature: modifiable EM perf_state table.
>> 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.
> 
> It's important to say that EAS is the _only_user of the `runtime
> modifiable EM`. All the other users (thermal, etc.) are still using the
> default (basic) EM. IMHO, this fact drove the design here.

OK, I'll add that information in the header.

> 
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>>   include/linux/energy_model.h | 13 +++++++++++++
>>   kernel/power/energy_model.c  | 24 ++++++++++++++++++++++++
>>   2 files changed, 37 insertions(+)
>>
>> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
>> index cc2bf607191e..a616006a8130 100644
>> --- a/include/linux/energy_model.h
>> +++ b/include/linux/energy_model.h
>> @@ -36,9 +36,21 @@ struct em_perf_state {
>>    */
>>   #define EM_PERF_STATE_INEFFICIENT BIT(0)
>>   
>> +/**
>> + * struct em_perf_table - Performance states table, which can be
>> + *		runtime modifiable and protected with RCU
> 
> which is `runtime modifiable` ? So `runtime modifiable performance state
> table`? RCU is obvious since we have `struct rcu_head rcu`.

Thanks, 'Runtime modifiable performance state table' sounds better.

> 
>> + * @state:	List of performance states, in ascending order
>> + * @rcu:	RCU used for safe access and destruction
>> + */
>> +struct em_perf_table {
>> +	struct em_perf_state *state;
>> +	struct rcu_head rcu;
>> +};
>> +
>>   /**
>>    * struct em_perf_domain - Performance domain
>>    * @table:		List of performance states, in ascending order
>> + * @runtime_table:	Pointer to the runtime modified em_perf_table
> 
> s/modified/modifiable
> 
> [...]
> 
>> @@ -237,12 +238,23 @@ static int em_create_pd(struct device *dev, int nr_states,
>>   			return -ENOMEM;
>>   	}
>>   
>> +	runtime_table = kzalloc(sizeof(*runtime_table), GFP_KERNEL);
>> +	if (!runtime_table) {
>> +		kfree(pd);
>> +		return -ENOMEM;
>> +	}
>> +
>>   	ret = em_create_perf_table(dev, pd, nr_states, cb, flags);
>>   	if (ret) {
>>   		kfree(pd);
>> +		kfree(runtime_table);
>>   		return ret;
>>   	}
>>   
>> +	/* Re-use temporally (till 1st modification) the memory */
> 
> So this means that the runtime (modifiable) table
> (pd->runtime_table>state) is mapped to the default (basic) table
> (pd->default_table->state) until the first call to
> em_dev_update_perf_domain() (here mentioned as the 1st modification)?

correct

> 
> IMHO, not easy to understand since neither the cover letter, nor
> documentation patch 15/17 describes this in a consistent story.

I'll add that to the patch header and also to the documentation patch
which is later in the series.


  reply	other threads:[~2023-07-03 15:58 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-12  9:57 [PATCH v2 00/17] Introduce runtime modifiable Energy Model Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 01/17] PM: EM: Refactor em_cpufreq_update_efficiencies() arguments Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 02/17] PM: EM: Find first CPU online while updating OPP efficiency Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 03/17] PM: EM: Refactor em_pd_get_efficient_state() to be more flexible Lukasz Luba
2023-05-30 11:06   ` Dietmar Eggemann
2023-07-03 16:22     ` Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 04/17] PM: EM: Create a new function em_compute_costs() Lukasz Luba
2023-05-30  9:51   ` Dietmar Eggemann
2023-07-03 15:09     ` Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 05/17] trace: energy_model: Add trace event for EM runtime modifications Lukasz Luba
2023-05-30 10:03   ` Dietmar Eggemann
2023-07-03 15:53     ` Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 06/17] PM: EM: Add update_power() callback for " Lukasz Luba
2023-05-30  9:31   ` Dietmar Eggemann
2023-07-03 15:06     ` Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 07/17] PM: EM: Check if the get_cost() callback is present in em_compute_costs() Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 08/17] PM: EM: Introduce runtime modifiable table Lukasz Luba
2023-05-14  4:28   ` kernel test robot
2023-05-30 10:18   ` Dietmar Eggemann
2023-07-03 15:58     ` Lukasz Luba [this message]
2023-05-12  9:57 ` [PATCH v2 09/17] PM: EM: Add RCU mechanism which safely cleans the old data Lukasz Luba
2023-05-30 10:02   ` Dietmar Eggemann
2023-07-03 15:49     ` Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 10/17] PM: EM: Add runtime update interface to modify EM power Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 11/17] PM: EM: Use runtime modified EM for CPUs energy estimation in EAS Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 12/17] PM: EM: Add argument to get_cost() for runtime modification Lukasz Luba
2023-05-30  9:53   ` Dietmar Eggemann
2023-07-03 15:30     ` Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 13/17] PM: EM: Refactor struct em_perf_domain and add default_table Lukasz Luba
2023-05-30 10:23   ` Dietmar Eggemann
2023-07-03 16:00     ` Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 14/17] Documentation: EM: Add a new section about the design Lukasz Luba
2023-05-30 10:33   ` Dietmar Eggemann
2023-07-03 16:09     ` Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 15/17] Documentation: EM: Add a runtime modifiable EM design description Lukasz Luba
2023-05-30 10:42   ` Dietmar Eggemann
2023-07-03 16:13     ` Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 16/17] Documentation: EM: Add example with driver modifying the EM Lukasz Luba
2023-05-12  9:57 ` [PATCH v2 17/17] Documentation: EM: Describe the API of runtime modifications Lukasz Luba
2023-05-24 17:25 ` [PATCH v2 00/17] Introduce runtime modifiable Energy Model Rafael J. Wysocki
2023-07-03 11:08   ` Lukasz Luba
2023-05-30 11:07 ` Dietmar Eggemann
2023-07-03 16:35   ` 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=bcf297db-4878-84e2-842d-178b79d7abbe@arm.com \
    --to=lukasz.luba@arm.com \
    --cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.