diff mbox series

[v5,08/23] PM: EM: Introduce runtime modifiable table

Message ID 20231129110853.94344-9-lukasz.luba@arm.com
State Superseded
Headers show
Series Introduce runtime modifiable Energy Model | expand

Commit Message

Lukasz Luba Nov. 29, 2023, 11:08 a.m. UTC 
The new runtime table can be populated with a new power data to better
reflect the actual efficiency of the device e.g. CPU. 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 EM data at runtime safely.

Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
 include/linux/energy_model.h | 12 ++++++++
 kernel/power/energy_model.c  | 53 ++++++++++++++++++++++++++++++++++++
 2 files changed, 65 insertions(+)

Comments

Dietmar Eggemann Dec. 12, 2023, 6:50 p.m. UTC | #1 
On 29/11/2023 12:08, Lukasz Luba wrote:
> The new runtime table can be populated with a new power data to better
> reflect the actual efficiency of the device e.g. CPU. 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

Don't understand this sentence. So CPU power changes with higher
temperature and for longer running scenarios when other devices are
involved? Not getting the 2. part.

> change. The new EM framework is able to addresses this issue and change
> the EM data at runtime safely.

Maybe better:
The new EM framework addresses this issue by allowing to change the EM
data at runtime.

[...]
Lukasz Luba Dec. 19, 2023, 11:33 a.m. UTC | #2 
On 12/12/23 18:50, Dietmar Eggemann wrote:
> On 29/11/2023 12:08, Lukasz Luba wrote:
>> The new runtime table can be populated with a new power data to better
>> reflect the actual efficiency of the device e.g. CPU. 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
> 
> Don't understand this sentence. So CPU power changes with higher
> temperature and for longer running scenarios when other devices are
> involved? Not getting the 2. part.

Total power consists of:
1. dynamic power - related to the freq, voltage^2 and logic capacitance
    size involved in switching during the computation
2. static power - aka. leakage - depends on voltage and
    temperature of the silicon. The higher the temperature, the higher
    the static power.

When you heat up the SoC using e.g. GPU, you start seeing on our CPU
power plot in time a raising function. Even if your CPU was running
constantly the same workload and data for long time, this effect
will happen after you add the heat from GPU in the same chip die.

IMO this is not the right place to educate people about physics of
the chip... Some understating and higher level education would
be needed otherwise even the best patch header description won't help.
So, I would keep those patch descriptions simple.

Beside, I have explained that in a few LPC and OSPM conferences.
In the cover letter there are links to them.

> 
>> change. The new EM framework is able to addresses this issue and change
>> the EM data at runtime safely.
> 
> Maybe better:
> The new EM framework addresses this issue by allowing to change the EM
> data at runtime.
> 

Sounds good, I can change that.
diff mbox series

Patch

diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index 8069f526c9d8..1e618e431cac 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -36,9 +36,20 @@  struct em_perf_state {
  */
 #define EM_PERF_STATE_INEFFICIENT BIT(0)
 
+/**
+ * struct em_perf_table - Performance states table
+ * @rcu:	RCU used for safe access and destruction
+ * @state:	List of performance states, in ascending order
+ */
+struct em_perf_table {
+	struct rcu_head rcu;
+	struct em_perf_state state[];
+};
+
 /**
  * struct em_perf_domain - Performance domain
  * @table:		List of performance states, in ascending order
+ * @runtime_table:	Pointer to the runtime modifiable em_perf_table
  * @nr_perf_states:	Number of performance states
  * @flags:		See "em_perf_domain flags"
  * @cpus:		Cpumask covering the CPUs of the domain. It's here
@@ -54,6 +65,7 @@  struct em_perf_state {
  */
 struct em_perf_domain {
 	struct em_perf_state *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 99426b5eedb6..489287666705 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -23,6 +23,9 @@ 
  */
 static DEFINE_MUTEX(em_pd_mutex);
 
+static void em_cpufreq_update_efficiencies(struct device *dev,
+					   struct em_perf_state *table);
+
 static bool _is_cpu_device(struct device *dev)
 {
 	return (dev->bus == &cpu_subsys);
@@ -103,6 +106,31 @@  static void em_debug_create_pd(struct device *dev) {}
 static void em_debug_remove_pd(struct device *dev) {}
 #endif
 
+static void em_destroy_table_rcu(struct rcu_head *rp)
+{
+	struct em_perf_table __rcu *runtime_table;
+
+	runtime_table = container_of(rp, struct em_perf_table, rcu);
+	kfree(runtime_table);
+}
+
+static void em_free_table(struct em_perf_table __rcu *table)
+{
+	call_rcu(&table->rcu, em_destroy_table_rcu);
+}
+
+static struct em_perf_table __rcu *
+em_allocate_table(struct em_perf_domain *pd)
+{
+	struct em_perf_table __rcu *table;
+	int table_size;
+
+	table_size = sizeof(struct em_perf_state) * pd->nr_perf_states;
+
+	table = kzalloc(sizeof(*table) + table_size, GFP_KERNEL);
+	return table;
+}
+
 static int em_compute_costs(struct device *dev, struct em_perf_state *table,
 			    struct em_data_callback *cb, int nr_states,
 			    unsigned long flags)
@@ -153,6 +181,24 @@  static int em_allocate_perf_table(struct em_perf_domain *pd,
 	return 0;
 }
 
+static int em_create_runtime_table(struct em_perf_domain *pd)
+{
+	struct em_perf_table __rcu *runtime_table;
+	int table_size;
+
+	runtime_table = em_allocate_table(pd);
+	if (!runtime_table)
+		return -ENOMEM;
+
+	/* Initialize runtime table with existing data */
+	table_size = sizeof(struct em_perf_state) * pd->nr_perf_states;
+	memcpy(runtime_table->state, pd->table, table_size);
+
+	rcu_assign_pointer(pd->runtime_table, runtime_table);
+
+	return 0;
+}
+
 static int em_create_perf_table(struct device *dev, struct em_perf_domain *pd,
 				struct em_perf_state *table,
 				int nr_states, struct em_data_callback *cb,
@@ -244,6 +290,10 @@  static int em_create_pd(struct device *dev, int nr_states,
 	if (ret)
 		goto free_pd_table;
 
+	ret = em_create_runtime_table(pd);
+	if (ret)
+		goto free_pd_table;
+
 	if (_is_cpu_device(dev))
 		for_each_cpu(cpu, cpus) {
 			cpu_dev = get_cpu_device(cpu);
@@ -460,6 +510,9 @@  void em_dev_unregister_perf_domain(struct device *dev)
 	em_debug_remove_pd(dev);
 
 	kfree(dev->em_pd->table);
+
+	em_free_table(dev->em_pd->runtime_table);
+
 	kfree(dev->em_pd);
 	dev->em_pd = NULL;
 	mutex_unlock(&em_pd_mutex);