linux-kernel - [PATCH 2/2] cpufreq: cppc: Add comments for CPPC_EM_COST

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <tencent_2353FA17ABE475CC48686CA43867C9D6A605@qq.com>
Date: Wed,  9 Apr 2025 17:51:50 +0800
From: Yaxiong Tian <iambestgod@...com>
To: rafael@...nel.org,
	viresh.kumar@...aro.org,
	Pierre.Gondois@....com
Cc: linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Yaxiong Tian <tianyaxiong@...inos.cn>
Subject: [PATCH 2/2] cpufreq: cppc: Add comments for CPPC_EM_COST_GAP calculation

From: Yaxiong Tian <tianyaxiong@...inos.cn>

The existing comments about CPPC_EM_COST_GAP were too brief. To help other
developers better understand its design rationale, this commit adds detailed
explanations about it.

Signed-off-by: Yaxiong Tian <tianyaxiong@...inos.cn>
---
 drivers/cpufreq/cppc_cpufreq.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index 756034b21682..c8e281ca95c0 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -358,7 +358,34 @@ static void cppc_cpufreq_register_em(struct cpufreq_policy *policy);
 #define CPPC_EM_CAP_STEP	(20)
 /* Increase the cost value by CPPC_EM_COST_STEP every performance state. */
 #define CPPC_EM_COST_STEP	(1)
-/* Add a cost gap correspnding to the energy of 4 CPUs. */
+
+/*
+ * In the current EM (Energy Model), energy consumption is calculated as:
+ *   ps->cost * sum_util;
+ *
+ * For CPPC, the cost calculation uses a linear model: cost = a + b * step.
+ *
+ * For a task A with utilization 'util' in a performance domain (pd):
+ * Before placement:
+ *   energy_pd_before = a * sum_util_pd + b * step * sum_util_pd;
+ * After placement:
+ *   energy_pd_after = a * (sum_util_pd + util) + b * (sum_util_pd + util) *
+ *                    (step + util/CPPC_EM_CAP_STEP);
+ * Energy difference:
+ *   energy_diff = a * util + b * util * step_pd +
+ *                 b * (sum_util_pd + util) * util/cap_step
+ *
+ * The placement decision depends on the bias 'a' and slope 'b'. Considering the
+ * extreme case where little cores are nearly full and big cores are nearly idle:
+ *   energy_diff_pd = a_diff * util - b * util * step_pd_small -
+ *                 b * util * sum_util_pd_small/cap_step
+ *
+ * Ignoring smaller terms, the key condition becomes:
+ *   a_diff > b * sum_util_pd_small / step_cap
+ *
+ * Therefore, for a pd domain with 4 CPUs, for ensures the scheduler will prefer
+ * placing it.we can configure accordingly.
+ */
 #define CPPC_EM_COST_GAP	(4 * SCHED_CAPACITY_SCALE * CPPC_EM_COST_STEP \
 				/ CPPC_EM_CAP_STEP)
 
-- 
2.25.1