Adjustments for preferred core detection

-----Original Message-----
From: Mario Limonciello <[email protected]>
Sent: Tuesday, August 27, 2024 5:14 AM
To: Borislav Petkov <[email protected]>; Shenoy, Gautham Ranjal <[email protected]>; Yuan, Perry <[email protected]>
Cc: maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; Rafael J . Wysocki <[email protected]>; open list:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; open list:ACPI <linux- [email protected]>; open list:CPU FREQUENCY SCALING FRAMEWORK <[email protected]>; Limonciello, Mario <[email protected]>
Subject: [PATCH 1/8] x86/amd: Move amd_get_highest_perf() from amd.c to cppc.c

From: Mario Limonciello <[email protected]>

To prepare to let amd_get_highest_perf() detect preferred cores it will require CPPC functions. Move amd_get_highest_perf() to cppc.c to prepare for 'preferred core detection' rework.

No functional changes intended.

Signed-off-by Mario Limonciello <[email protected]>

---
 arch/x86/kernel/acpi/cppc.c | 16 ++++++++++++++++
 arch/x86/kernel/cpu/amd.c   | 16 ----------------
 2 files changed, 16 insertions(+), 16 deletions(-)

arch/x86/kernel/acpi/cppc.c index renamed from arch/x86/kernel/acpi/cppc.c +0 -0

ff8f25faca3dd..7ec8f2ce859c8 100644

arch/x86/kernel/acpi/cppc.c +6 -0

@@ -116,3 +116,19 @@ void init_freq_invariance_cppc(void)
      init_done = true;
      mutex_unlock(&freq_invariance_lock);
 }
+
+u32 amd_get_highest_perf(void)
+{
+     struct cpuinfo_x86 *c = &boot_cpu_data;
+
+     if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model <

0x40) ||
+ (c->x86_model >= 0x70 && c->x86_model <
0x80)))

arch/x86/kernel/acpi/cppc.c +3 -0

+             return 166;
+
+     if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model <

0x30) ||
+ (c->x86_model >= 0x40 && c->x86_model <
0x70)))

arch/x86/kernel/acpi/cppc.c +5 -0

+             return 166;
+
+     return 255;
+}
+EXPORT_SYMBOL_GPL(amd_get_highest_perf);

arch/x86/kernel/cpu/amd.c index renamed from arch/x86/kernel/cpu/amd.c +0 -0

1e0fe5f8ab84e..015971adadfc7 100644

arch/x86/kernel/cpu/amd.c +0 -5

@@ -1190,22 +1190,6 @@ unsigned long amd_get_dr_addr_mask(unsigned
 int dr)  }  EXPORT_SYMBOL_GPL(amd_get_dr_addr_mask);
 
-u32 amd_get_highest_perf(void)
-{
-     struct cpuinfo_x86 *c = &boot_cpu_data;
-
-     if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model <

0x40) ||
- (c->x86_model >= 0x70 && c->x86_model <
0x80)))

arch/x86/kernel/cpu/amd.c +0 -3

-             return 166;
-
-     if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model <

0x30) ||
- (c->x86_model >= 0x40 && c->x86_model <
0x70)))

arch/x86/kernel/cpu/amd.c +0 -7

-             return 166;
-
-     return 255;
-}
-EXPORT_SYMBOL_GPL(amd_get_highest_perf);
-
 static void zenbleed_check_cpu(void *unused)  {
      struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
--

2.43.0

From: Mario Limonciello <[email protected]>

To prepare to let amd_get_highest_perf() detect preferred cores it will require CPPC functions. Move amd_get_highest_perf() to cppc.c to prepare for 'preferred core detection' rework.

No functional changes intended.

Signed-off-by Mario Limonciello <[email protected]>

---
 arch/x86/kernel/acpi/cppc.c | 16 ++++++++++++++++
 arch/x86/kernel/cpu/amd.c   | 16 ----------------
 2 files changed, 16 insertions(+), 16 deletions(-)

arch/x86/kernel/acpi/cppc.c +16 -0

index ff8f25faca3dd..7ec8f2ce859c8 100644
@@ -116,3 +116,19 @@ void init_freq_invariance_cppc(void)
 	init_done = true;
 	mutex_unlock(&freq_invariance_lock);
 }
+
+u32 amd_get_highest_perf(void)
+{
+	struct cpuinfo_x86 *c = &boot_cpu_data;
+
+	if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
+			       (c->x86_model >= 0x70 && c->x86_model < 0x80)))
+		return 166;
+
+	if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
+			       (c->x86_model >= 0x40 && c->x86_model < 0x70)))
+		return 166;
+
+	return 255;
+}
+EXPORT_SYMBOL_GPL(amd_get_highest_perf);

arch/x86/kernel/cpu/amd.c +0 -16

index 1e0fe5f8ab84e..015971adadfc7 100644
@@ -1190,22 +1190,6 @@ unsigned long amd_get_dr_addr_mask(unsigned int dr)
 }
 EXPORT_SYMBOL_GPL(amd_get_dr_addr_mask);
 
-u32 amd_get_highest_perf(void)
-{
-	struct cpuinfo_x86 *c = &boot_cpu_data;
-
-	if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
-			       (c->x86_model >= 0x70 && c->x86_model < 0x80)))
-		return 166;
-
-	if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
-			       (c->x86_model >= 0x40 && c->x86_model < 0x70)))
-		return 166;
-
-	return 255;
-}
-EXPORT_SYMBOL_GPL(amd_get_highest_perf);
-
 static void zenbleed_check_cpu(void *unused)
 {
 	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());

Signature · 1 line

2.43.0

From: Mario Limonciello <[email protected]>

The function name is ambiguous because it returns an intermediate value for calculating maximum frequency rather than the CPPC 'Highest Perf' register.

Rename the function to clarify its use and allow the function to return errors. Adjust the consumer in acpi-cpufreq to catch errors.

Signed-off-by Mario Limonciello <[email protected]>

arch/x86/kernel/acpi/cppc.c +25 -9

 	nominal_perf = perf_caps.nominal_perf;
 
-	if (!highest_perf || !nominal_perf) {
-		pr_debug("Could not retrieve highest or nominal performance\n");
+	if (!nominal_perf) {
+		pr_debug("Could not retrieve nominal performance\n");
 		return;
 	}
 

@@ -117,18 +119,34 @@ void init_freq_invariance_cppc(void)
 	mutex_unlock(&freq_invariance_lock);
 }
 
-u32 amd_get_highest_perf(void)
+/**
+ * amd_get_boost_ratio_numerator: Get the numerator to use for boost ratio calculation
+ * @cpu: CPU to get numerator for.
+ * @numerator: Output variable for numerator.
+ *
+ * Determine the numerator to use for calculating the boost ratio on
+ * a CPU. On systems that support preferred cores, this will be a hardcoded
+ * value. On other systems this will the highest performance register value.
+ *
+ * Return: 0 for success, negative error code otherwise.
+ */
+int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
 {
 	struct cpuinfo_x86 *c = &boot_cpu_data;
 
 	if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
-			       (c->x86_model >= 0x70 && c->x86_model < 0x80)))
-		return 166;
+			       (c->x86_model >= 0x70 && c->x86_model < 0x80))) {
+		*numerator = 166;
+		return 0;
+	}
 
 	if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
-			       (c->x86_model >= 0x40 && c->x86_model < 0x70)))
-		return 166;
+			       (c->x86_model >= 0x40 && c->x86_model < 0x70))) {
+		*numerator = 166;
+		return 0;
+	}
+	*numerator = 255;
 
-	return 255;
+	return 0;
 }
-EXPORT_SYMBOL_GPL(amd_get_highest_perf);
+EXPORT_SYMBOL_GPL(amd_get_boost_ratio_numerator);

drivers/cpufreq/acpi-cpufreq.c +9 -3

index a8ca625a98b89..0f04feb6cafaf 100644
@@ -642,10 +642,16 @@ static u64 get_max_boost_ratio(unsigned int cpu)
 		return 0;
 	}
 
-	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
-		highest_perf = amd_get_highest_perf();
-	else
+	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+		ret = amd_get_boost_ratio_numerator(cpu, &highest_perf);
+		if (ret) {
+			pr_debug("CPU%d: Unable to get boost ratio numerator (%d)\n",
+				 cpu, ret);
+			return 0;
+		}
+	} else {
 		highest_perf = perf_caps.highest_perf;
+	}
 
 	nominal_perf = perf_caps.nominal_perf;
 

include/acpi/cppc_acpi.h +6 -0

index 930b6afba6f4d..f25a881cd46dd 100644
@@ -136,6 +136,12 @@ struct cppc_cpudata {
 	cpumask_var_t shared_cpu_map;
 };
 
+#ifdef CONFIG_CPU_SUP_AMD
+extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator);
+#else /* !CONFIG_CPU_SUP_AMD */
+static inline int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator) { return -ENODEV; }
+#endif /* !CONFIG_CPU_SUP_AMD */
+
 #ifdef CONFIG_ACPI_CPPC_LIB
 extern int cppc_get_desired_perf(int cpunum, u64 *desired_perf);
 extern int cppc_get_nominal_perf(int cpunum, u64 *nominal_perf);

Signature · 1 line

2.43.0

Hello Mario,

Quoted 10 lines · Mario Limonciello

From: Mario Limonciello <[email protected]>

The function name is ambiguous because it returns an intermediate value for calculating maximum frequency rather than the CPPC 'Highest Perf' register.

Rename the function to clarify its use and allow the function to return errors. Adjust the consumer in acpi-cpufreq to catch errors.

Signed-off-by Mario Limonciello <[email protected]>

[..snip..]

arch/x86/kernel/acpi/cppc.c static void amd_set_max_freq_ratio(void) · line 82

Quoted 8 lines

arch/x86/kernel/acpi/cppc.c +1 -1

@@ -79,11 +79,13 @@ static void amd_set_max_freq_ratio(void)
  		return;
  	}
 
-	highest_perf = amd_get_highest_perf();
+	rc = amd_get_boost_ratio_numerator(0, &highest_perf);

The variable is still named highest_perf, here! I suppose that will change in a subsequent patch?

arch/x86/kernel/acpi/cppc.c static void amd_set_max_freq_ratio(void) · line 84

Quoted 2 lines

arch/x86/kernel/acpi/cppc.c +2 -0

+	if (rc)
+		pr_debug("Could not retrieve highest performance\n");

I understand that amd_get_boost_ratio_numerator() always returns a 0 in this patch and thus rc == 0, which means we never enter this "if" condition.

However, when rc is non-zero, shouldn't this function return after printing the debug message?

--
Thanks and Regards
gautham.

Quoted 95 lines

arch/x86/kernel/acpi/cppc.c +25 -9

  	nominal_perf = perf_caps.nominal_perf;
 
-	if (!highest_perf || !nominal_perf) {
-		pr_debug("Could not retrieve highest or nominal performance\n");
+	if (!nominal_perf) {
+		pr_debug("Could not retrieve nominal performance\n");
  		return;
  	}
 

@@ -117,18 +119,34 @@ void init_freq_invariance_cppc(void)
  	mutex_unlock(&freq_invariance_lock);
  }
 
-u32 amd_get_highest_perf(void)
+/**
+ * amd_get_boost_ratio_numerator: Get the numerator to use for boost ratio calculation
+ * @cpu: CPU to get numerator for.
+ * @numerator: Output variable for numerator.
+ *
+ * Determine the numerator to use for calculating the boost ratio on
+ * a CPU. On systems that support preferred cores, this will be a hardcoded
+ * value. On other systems this will the highest performance register value.
+ *
+ * Return: 0 for success, negative error code otherwise.
+ */
+int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
  {
  	struct cpuinfo_x86 *c = &boot_cpu_data;
 
  	if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
-			       (c->x86_model >= 0x70 && c->x86_model < 0x80)))
-		return 166;
+			       (c->x86_model >= 0x70 && c->x86_model < 0x80))) {
+		*numerator = 166;
+		return 0;
+	}
 
  	if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
-			       (c->x86_model >= 0x40 && c->x86_model < 0x70)))
-		return 166;
+			       (c->x86_model >= 0x40 && c->x86_model < 0x70))) {
+		*numerator = 166;
+		return 0;
+	}
+	*numerator = 255;
 
-	return 255;
+	return 0;
  }
-EXPORT_SYMBOL_GPL(amd_get_highest_perf);
+EXPORT_SYMBOL_GPL(amd_get_boost_ratio_numerator);

drivers/cpufreq/acpi-cpufreq.c +9 -3

index a8ca625a98b89..0f04feb6cafaf 100644
@@ -642,10 +642,16 @@ static u64 get_max_boost_ratio(unsigned int cpu)
  		return 0;
  	}
 
-	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
-		highest_perf = amd_get_highest_perf();
-	else
+	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+		ret = amd_get_boost_ratio_numerator(cpu, &highest_perf);
+		if (ret) {
+			pr_debug("CPU%d: Unable to get boost ratio numerator (%d)\n",
+				 cpu, ret);
+			return 0;
+		}
+	} else {
  		highest_perf = perf_caps.highest_perf;
+	}
 
  	nominal_perf = perf_caps.nominal_perf;
 

include/acpi/cppc_acpi.h +6 -0

index 930b6afba6f4d..f25a881cd46dd 100644
@@ -136,6 +136,12 @@ struct cppc_cpudata {
  	cpumask_var_t shared_cpu_map;
  };
 
+#ifdef CONFIG_CPU_SUP_AMD
+extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator);
+#else /* !CONFIG_CPU_SUP_AMD */
+static inline int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator) { return -ENODEV; }
+#endif /* !CONFIG_CPU_SUP_AMD */
+
  #ifdef CONFIG_ACPI_CPPC_LIB
  extern int cppc_get_desired_perf(int cpunum, u64 *desired_perf);
  extern int cppc_get_nominal_perf(int cpunum, u64 *nominal_perf);

Signature · 1 line

2.43.0

-----Original Message-----
From: Mario Limonciello <[email protected]>
Sent: Tuesday, August 27, 2024 5:14 AM
To: Borislav Petkov <[email protected]>; Shenoy, Gautham Ranjal <[email protected]>; Yuan, Perry <[email protected]>
Cc: maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; Rafael J . Wysocki <[email protected]>; open list:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; open list:ACPI <linux- [email protected]>; open list:CPU FREQUENCY SCALING FRAMEWORK <[email protected]>; Limonciello, Mario <[email protected]>; Yuan, Perry <[email protected]>
Subject: [PATCH 3/8] ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn

From: Mario Limonciello <[email protected]>

If the boost ratio isn't calculated properly for the system for any reason this can cause other problems that are non-obvious.

Raise all messages to warn instead.

Suggested-by Perry Yuan <[email protected]>

Signed-off-by Mario Limonciello <[email protected]>

---
 arch/x86/kernel/acpi/cppc.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/x86/kernel/acpi/cppc.c index renamed from arch/x86/kernel/acpi/cppc.c +0 -0

1d631ac5ec328..e94507110ca24 100644

arch/x86/kernel/acpi/cppc.c +4 -4

@@ -75,17 +75,17 @@ static void amd_set_max_freq_ratio(void)
 
      rc = cppc_get_perf_caps(0, &perf_caps);
      if (rc) {
-             pr_debug("Could not retrieve perf counters (%d)\n", rc);
+             pr_warn("Could not retrieve perf counters (%d)\n", rc);
              return;
      }
 
      rc = amd_get_boost_ratio_numerator(0, &highest_perf);
      if (rc)
-             pr_debug("Could not retrieve highest performance\n");
+             pr_warn("Could not retrieve highest performance\n");
      nominal_perf = perf_caps.nominal_perf;
 
      if (!nominal_perf) {
-             pr_debug("Could not retrieve nominal performance\n");
+             pr_warn("Could not retrieve nominal performance\n");
              return;
      }
 

@@ -93,7 +93,7 @@ static void amd_set_max_freq_ratio(void)
      /* midpoint between max_boost and max_P */
      perf_ratio = (perf_ratio + SCHED_CAPACITY_SCALE) >> 1;
      if (!perf_ratio) {
-             pr_debug("Non-zero highest/nominal perf values led to a 0
 ratio\n");
+             pr_warn("Non-zero highest/nominal perf values led to a 0
 ratio\n");
              return;

      }

--
2.43.0

From: Mario Limonciello <[email protected]>

If the boost ratio isn't calculated properly for the system for any reason this can cause other problems that are non-obvious.

Raise all messages to warn instead.

Suggested-by Perry Yuan <[email protected]>

Signed-off-by Mario Limonciello <[email protected]>

---
 arch/x86/kernel/acpi/cppc.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/x86/kernel/acpi/cppc.c +3 -3

index 1d631ac5ec328..e94507110ca24 100644
@@ -75,17 +75,17 @@ static void amd_set_max_freq_ratio(void)
 
 	rc = cppc_get_perf_caps(0, &perf_caps);
 	if (rc) {
-		pr_debug("Could not retrieve perf counters (%d)\n", rc);
+		pr_warn("Could not retrieve perf counters (%d)\n", rc);
 		return;
 	}
 
 	rc = amd_get_boost_ratio_numerator(0, &highest_perf);
 	if (rc)
-		pr_debug("Could not retrieve highest performance\n");
+		pr_warn("Could not retrieve highest performance\n");
 	nominal_perf = perf_caps.nominal_perf;
 
 	if (!nominal_perf) {
-		pr_debug("Could not retrieve nominal performance\n");
+		pr_warn("Could not retrieve nominal performance\n");
 		return;
 	}
 

Quoted 39 lines · Mario Limonciello

From: Mario Limonciello <[email protected]>

If the boost ratio isn't calculated properly for the system for any reason this can cause other problems that are non-obvious.

Raise all messages to warn instead.

Suggested-by Perry Yuan <[email protected]>

Signed-off-by Mario Limonciello <[email protected]>

---
  arch/x86/kernel/acpi/cppc.c | 8 ++++----
  1 file changed, 4 insertions(+), 4 deletions(-)

arch/x86/kernel/acpi/cppc.c +3 -3

index 1d631ac5ec328..e94507110ca24 100644
@@ -75,17 +75,17 @@ static void amd_set_max_freq_ratio(void)
 
  	rc = cppc_get_perf_caps(0, &perf_caps);
  	if (rc) {
-		pr_debug("Could not retrieve perf counters (%d)\n", rc);
+		pr_warn("Could not retrieve perf counters (%d)\n", rc);
  		return;
  	}
 
  	rc = amd_get_boost_ratio_numerator(0, &highest_perf);
  	if (rc)
-		pr_debug("Could not retrieve highest performance\n");
+		pr_warn("Could not retrieve highest performance\n");
  	nominal_perf = perf_caps.nominal_perf;
 
  	if (!nominal_perf) {
-		pr_debug("Could not retrieve nominal performance\n");
+		pr_warn("Could not retrieve nominal performance\n");
  		return;
  	}
 

arch/x86/kernel/acpi/cppc.c static void amd_set_max_freq_ratio(void) · line 97

Quoted 6 lines

arch/x86/kernel/acpi/cppc.c +1 -1

@@ -93,7 +93,7 @@ static void amd_set_max_freq_ratio(void)
  	/* midpoint between max_boost and max_P */
  	perf_ratio = (perf_ratio + SCHED_CAPACITY_SCALE) >> 1;
  	if (!perf_ratio) {
-		pr_debug("Non-zero highest/nominal perf values led to a 0 ratio\n");
+		pr_warn("Non-zero highest/nominal perf values led to a 0 ratio\n");
  		return;

Aside:
perf_ratio is a u64, and SCHED_CAPACITY_SCALE is (1L << 10). Thus, is it even possible to have !perf_ratio?

Otherwise, I am ok with this promotion of pr_debug to pr_warn.

Reviewed-by Gautham R. Shenoy <[email protected]>

--
Thanks and Regards
gautham.

-----Original Message-----
From: Mario Limonciello <[email protected]>
Sent: Tuesday, August 27, 2024 5:14 AM
To: Borislav Petkov <[email protected]>; Shenoy, Gautham Ranjal <[email protected]>; Yuan, Perry <[email protected]>
Cc: maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; Rafael J . Wysocki <[email protected]>; open list:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; open list:ACPI <linux- [email protected]>; open list:CPU FREQUENCY SCALING FRAMEWORK <[email protected]>; Limonciello, Mario <[email protected]>
Subject: [PATCH 4/8] x86/amd: Move amd_get_highest_perf() out of amd- pstate

From: Mario Limonciello <[email protected]>

amd_get_highest_perf() is a helper used to get the highest perf value on AMD systems. It's used in amd-pstate as part of preferred core handling, but applicable for acpi-cpufreq as well.

Move it out to cppc handling code.

Signed-off-by Mario Limonciello <[email protected]>

---
 arch/x86/kernel/acpi/cppc.c  | 30 ++++++++++++++++++++++++++++++
drivers/cpufreq/amd-pstate.c | 34 ++--------------------------------
 include/acpi/cppc_acpi.h     |  2 ++
 3 files changed, 34 insertions(+), 32 deletions(-)

arch/x86/kernel/acpi/cppc.c index renamed from arch/x86/kernel/acpi/cppc.c +0 -0

e94507110ca24..5a6c01a1b0d95 100644

arch/x86/kernel/acpi/cppc.c +29 -0

@@ -119,6 +119,36 @@ void init_freq_invariance_cppc(void)
      mutex_unlock(&freq_invariance_lock);
 }
 
+/*
+ * Get the highest performance register value.
+ * @cpu: CPU from which to get highest performance.
+ * @highest_perf: Return address for highest performance value.
+ *
+ * Return: 0 for success, negative error code otherwise.
+ */
+int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf) {
+     u64 val;
+     int ret;
+
+     if (cpu_feature_enabled(X86_FEATURE_CPPC)) {
+             ret = rdmsrl_safe_on_cpu(cpu, MSR_AMD_CPPC_CAP1, &val);
+             if (ret)
+                     goto out;
+
+             val = AMD_CPPC_HIGHEST_PERF(val);
+     } else {
+             ret = cppc_get_highest_perf(cpu, &val);
+             if (ret)
+                     goto out;
+     }
+
+     WRITE_ONCE(*highest_perf, (u32)val);
+out:
+     return ret;
+}
+EXPORT_SYMBOL_GPL(amd_get_highest_perf);
+
 /**
  * amd_get_boost_ratio_numerator: Get the numerator to use for boost ratio

calculation
* @cpu: CPU to get numerator for.

drivers/cpufreq/amd-pstate.c +0 -0

index 89bda7a2bb8d1..f470b5700db58 100644
@@ -803,36 +803,6 @@ static void

amd_pstste_sched_prefcore_workfn(struct work_struct *work) } static DECLARE_WORK(sched_prefcore_work, amd_pstste_sched_prefcore_workfn);

drivers/cpufreq/amd-pstate.c +0 -14

-/*
- * Get the highest performance register value.
- * @cpu: CPU from which to get highest performance.
- * @highest_perf: Return address.
- *
- * Return: 0 for success, -EIO otherwise.
- */
-static int amd_pstate_get_highest_perf(int cpu, u32 *highest_perf) -{
-     int ret;
-
-     if (cpu_feature_enabled(X86_FEATURE_CPPC)) {
-             u64 cap1;
-
-             ret = rdmsrl_safe_on_cpu(cpu, MSR_AMD_CPPC_CAP1,

&cap1);

drivers/cpufreq/amd-pstate.c +0 -3

-             if (ret)
-                     return ret;
-             WRITE_ONCE(*highest_perf,

AMD_CPPC_HIGHEST_PERF(cap1));

drivers/cpufreq/amd-pstate.c +0 -12

-     } else {
-             u64 cppc_highest_perf;
-
-             ret = cppc_get_highest_perf(cpu, &cppc_highest_perf);
-             if (ret)
-                     return ret;
-             WRITE_ONCE(*highest_perf, cppc_highest_perf);
-     }
-
-     return (ret);
-}
-
 #define CPPC_MAX_PERF        U8_MAX
 
 static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata) @@ -

840,7 +810,7 @@ static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata)

      int ret, prio;
      u32 highest_perf;

drivers/cpufreq/amd-pstate.c +2 -2

-     ret = amd_pstate_get_highest_perf(cpudata->cpu, &highest_perf);
+     ret = amd_get_highest_perf(cpudata->cpu, &highest_perf);
      if (ret)
              return;

@@ -879,7 +849,7 @@ static void amd_pstate_update_limits(unsigned int
 cpu)
      if ((!amd_pstate_prefcore) || (!cpudata->hw_prefcore))
              goto free_cpufreq_put;
 
-     ret = amd_pstate_get_highest_perf(cpu, &cur_high);
+     ret = amd_get_highest_perf(cpu, &cur_high);
      if (ret)
              goto free_cpufreq_put;

include/acpi/cppc_acpi.h index renamed from include/acpi/cppc_acpi.h +0 -0

f25a881cd46dd..2246ce0630362 100644

include/acpi/cppc_acpi.h +3 -1

@@ -137,8 +137,10 @@ struct cppc_cpudata {  };
 
 #ifdef CONFIG_CPU_SUP_AMD
+extern int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf);
 extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64
 *numerator);  #else /* !CONFIG_CPU_SUP_AMD */
+static inline int amd_get_highest_perf(unsigned int cpu, u32
+*highest_perf) { return -ENODEV; }
 static inline int amd_get_boost_ratio_numerator(unsigned int cpu, u64
 *numerator) { return -ENODEV; }  #endif /* !CONFIG_CPU_SUP_AMD */
 
--

2.43.0

From: Mario Limonciello <[email protected]>

amd_get_highest_perf() is a helper used to get the highest perf

value on AMD systems. It's used in amd-pstate as part of preferred core handling, but applicable for acpi-cpufreq as well.

Move it out to cppc handling code.

Signed-off-by Mario Limonciello <[email protected]>

---
 arch/x86/kernel/acpi/cppc.c  | 30 ++++++++++++++++++++++++++++++
 drivers/cpufreq/amd-pstate.c | 34 ++--------------------------------
 include/acpi/cppc_acpi.h     |  2 ++
 3 files changed, 34 insertions(+), 32 deletions(-)

arch/x86/kernel/acpi/cppc.c +30 -0

index e94507110ca24..5a6c01a1b0d95 100644
@@ -119,6 +119,36 @@ void init_freq_invariance_cppc(void)
 	mutex_unlock(&freq_invariance_lock);
 }
 
+/*
+ * Get the highest performance register value.
+ * @cpu: CPU from which to get highest performance.
+ * @highest_perf: Return address for highest performance value.
+ *
+ * Return: 0 for success, negative error code otherwise.
+ */
+int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf)
+{
+	u64 val;
+	int ret;
+
+	if (cpu_feature_enabled(X86_FEATURE_CPPC)) {
+		ret = rdmsrl_safe_on_cpu(cpu, MSR_AMD_CPPC_CAP1, &val);
+		if (ret)
+			goto out;
+
+		val = AMD_CPPC_HIGHEST_PERF(val);
+	} else {
+		ret = cppc_get_highest_perf(cpu, &val);
+		if (ret)
+			goto out;
+	}
+
+	WRITE_ONCE(*highest_perf, (u32)val);
+out:
+	return ret;
+}
+EXPORT_SYMBOL_GPL(amd_get_highest_perf);
+
 /**
  * amd_get_boost_ratio_numerator: Get the numerator to use for boost ratio calculation
  * @cpu: CPU to get numerator for.

drivers/cpufreq/amd-pstate.c +2 -32

index 89bda7a2bb8d1..f470b5700db58 100644
@@ -803,36 +803,6 @@ static void amd_pstste_sched_prefcore_workfn(struct work_struct *work)
 }
 static DECLARE_WORK(sched_prefcore_work, amd_pstste_sched_prefcore_workfn);
 
-/*
- * Get the highest performance register value.
- * @cpu: CPU from which to get highest performance.
- * @highest_perf: Return address.
- *
- * Return: 0 for success, -EIO otherwise.
- */
-static int amd_pstate_get_highest_perf(int cpu, u32 *highest_perf)
-{
-	int ret;
-
-	if (cpu_feature_enabled(X86_FEATURE_CPPC)) {
-		u64 cap1;
-
-		ret = rdmsrl_safe_on_cpu(cpu, MSR_AMD_CPPC_CAP1, &cap1);
-		if (ret)
-			return ret;
-		WRITE_ONCE(*highest_perf, AMD_CPPC_HIGHEST_PERF(cap1));
-	} else {
-		u64 cppc_highest_perf;
-
-		ret = cppc_get_highest_perf(cpu, &cppc_highest_perf);
-		if (ret)
-			return ret;
-		WRITE_ONCE(*highest_perf, cppc_highest_perf);
-	}
-
-	return (ret);
-}
-
 #define CPPC_MAX_PERF	U8_MAX
 
 static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata)

@@ -840,7 +810,7 @@ static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata)
 	int ret, prio;
 	u32 highest_perf;
 
-	ret = amd_pstate_get_highest_perf(cpudata->cpu, &highest_perf);
+	ret = amd_get_highest_perf(cpudata->cpu, &highest_perf);
 	if (ret)
 		return;
 

@@ -879,7 +849,7 @@ static void amd_pstate_update_limits(unsigned int cpu)
 	if ((!amd_pstate_prefcore) || (!cpudata->hw_prefcore))
 		goto free_cpufreq_put;
 
-	ret = amd_pstate_get_highest_perf(cpu, &cur_high);
+	ret = amd_get_highest_perf(cpu, &cur_high);
 	if (ret)
 		goto free_cpufreq_put;
 

include/acpi/cppc_acpi.h +2 -0

index f25a881cd46dd..2246ce0630362 100644
@@ -137,8 +137,10 @@ struct cppc_cpudata {
 };
 
 #ifdef CONFIG_CPU_SUP_AMD
+extern int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf);
 extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator);
 #else /* !CONFIG_CPU_SUP_AMD */
+static inline int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf) { return -ENODEV; }
 static inline int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator) { return -ENODEV; }
 #endif /* !CONFIG_CPU_SUP_AMD */
 

Signature · 1 line

2.43.0

From: Mario Limonciello <[email protected]>

AMD systems that support preferred cores will use "166" as their numerator for max frequency calculations instead of "255".

Add a function for detecting preferred cores by looking at the highest perf value on all cores.

If preferred cores are enabled return 166 and if disabled the value in the highest perf register. As the function will be called multiple times, cache the values for the boost numerator and if preferred cores will be enabled in global variables.

Signed-off-by Mario Limonciello <[email protected]>

---

/**
* amd_get_boost_ratio_numerator: Get the numerator to use for boost ratio calculation
* @cpu: CPU to get numerator for.

arch/x86/kernel/acpi/cppc.c +5 -6

@@ -162,20 +232,19 @@ EXPORT_SYMBOL_GPL(amd_get_highest_perf);
  */
 int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
 {
-	struct cpuinfo_x86 *c = &boot_cpu_data;
+	bool prefcore;
+	int ret;
 
-	if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
-			       (c->x86_model >= 0x70 && c->x86_model < 0x80))) {
-		*numerator = 166;
-		return 0;
-	}
+	ret = amd_detect_prefcore(&prefcore);
+	if (ret)
+		return ret;
 

(quoted diff) +0 -0

 	return 0;
 }

drivers/cpufreq/amd-pstate.c +13 -21

index f470b5700db58..ec32c830abc1d 100644
@@ -807,32 +807,18 @@ static DECLARE_WORK(sched_prefcore_work, amd_pstste_sched_prefcore_workfn);
 
 static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata)
 {
-	int ret, prio;
-	u32 highest_perf;
-
-	ret = amd_get_highest_perf(cpudata->cpu, &highest_perf);
-	if (ret)
+	/* user disabled or not detected */
+	if (!amd_pstate_prefcore)
 		return;
 
 	cpudata->hw_prefcore = true;
-	/* check if CPPC preferred core feature is enabled*/
-	if (highest_perf < CPPC_MAX_PERF)
-		prio = (int)highest_perf;
-	else {
-		pr_debug("AMD CPPC preferred core is unsupported!\n");
-		cpudata->hw_prefcore = false;
-		return;
-	}
-
-	if (!amd_pstate_prefcore)
-		return;
 
 	/*
 	 * The priorities can be set regardless of whether or not
 	 * sched_set_itmt_support(true) has been called and it is valid to
 	 * update them at any time after it has been called.
 	 */
-	sched_set_itmt_core_prio(prio, cpudata->cpu);
+	sched_set_itmt_core_prio((int)READ_ONCE(cpudata->highest_perf), cpudata->cpu);
 
 	schedule_work(&sched_prefcore_work);
 }

@@ -998,12 +984,12 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
 
 	cpudata->cpu = policy->cpu;
 
-	amd_pstate_init_prefcore(cpudata);
-
 	ret = amd_pstate_init_perf(cpudata);
 	if (ret)
 		goto free_cpudata1;
 
+	amd_pstate_init_prefcore(cpudata);
+
 	ret = amd_pstate_init_freq(cpudata);
 	if (ret)
 		goto free_cpudata1;

@@ -1453,12 +1439,12 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
 	cpudata->cpu = policy->cpu;
 	cpudata->epp_policy = 0;
 
-	amd_pstate_init_prefcore(cpudata);
-
 	ret = amd_pstate_init_perf(cpudata);
 	if (ret)
 		goto free_cpudata1;
 
+	amd_pstate_init_prefcore(cpudata);
+
 	ret = amd_pstate_init_freq(cpudata);
 	if (ret)
 		goto free_cpudata1;

@@ -1903,6 +1889,12 @@ static int __init amd_pstate_init(void)
 		static_call_update(amd_pstate_update_perf, cppc_update_perf);
 	}
 
+	if (amd_pstate_prefcore) {
+		ret = amd_detect_prefcore(&amd_pstate_prefcore);
+		if (ret)
+			return ret;
+	}
+
 	/* enable amd pstate feature */
 	ret = amd_pstate_enable(true);
 	if (ret) {

include/acpi/cppc_acpi.h +2 -0

index 2246ce0630362..1d79320a23490 100644
@@ -137,10 +137,12 @@ struct cppc_cpudata {
 };
 
 #ifdef CONFIG_CPU_SUP_AMD
+extern int amd_detect_prefcore(bool *detected);
 extern int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf);
 extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator);
 #else /* !CONFIG_CPU_SUP_AMD */
 static inline int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf) { return -ENODEV; }
+static inline int amd_detect_prefcore(bool *detected) { return -ENODEV; }
 static inline int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator) { return -ENODEV; }
 #endif /* !CONFIG_CPU_SUP_AMD */
 

Signature · 1 line

2.43.0

Quoted 15 lines · Mario Limonciello

From: Mario Limonciello <[email protected]>

AMD systems that support preferred cores will use "166" as their numerator for max frequency calculations instead of "255".

Add a function for detecting preferred cores by looking at the highest perf value on all cores.

If preferred cores are enabled return 166 and if disabled the value in the highest perf register. As the function will be called multiple times, cache the values for the boost numerator and if preferred cores will be enabled in global variables.

Signed-off-by Mario Limonciello <[email protected]>

---

[..snip..]

Quoted 20 lines

/**
* amd_get_boost_ratio_numerator: Get the numerator to use for boost ratio calculation
* @cpu: CPU to get numerator for.

arch/x86/kernel/acpi/cppc.c +5 -6

@@ -162,20 +232,19 @@ EXPORT_SYMBOL_GPL(amd_get_highest_perf);
   */
  int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
  {
-	struct cpuinfo_x86 *c = &boot_cpu_data;
+	bool prefcore;
+	int ret;
 
-	if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
-			       (c->x86_model >= 0x70 && c->x86_model < 0x80))) {
-		*numerator = 166;
-		return 0;
-	}
+	ret = amd_detect_prefcore(&prefcore);
+	if (ret)
+		return ret;
 

arch/x86/kernel/acpi/cppc.c EXPORT_SYMBOL_GPL(amd_get_highest_perf); · line 247

Quoted 10 lines

arch/x86/kernel/acpi/cppc.c +4 -4

-	if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
-			       (c->x86_model >= 0x40 && c->x86_model < 0x70))) {
-		*numerator = 166;
+	/* without preferred cores, return the highest perf register value */
+	if (!prefcore) {
+		*numerator = boost_numerator;
  		return 0;
  	}
-	*numerator = 255;
+	*numerator = CPPC_HIGHEST_PERF_PREFCORE;

Interesting. So even when the user boots a system that supports preferred-cores with "amd_preferred=disable", amd_get_boost_ratio_numerator() will return CPPC_HIGHEST_PERF_PREFCORE as the call prefcore == true here.

I suppose that is as intended, since even though the user may not want to use the preferred core logic for task-scheduling/load-balancing, the numerator for the boost-ratio is purely dependent on the h/w capability.

Is this understanding correct? If so, can this be included as a comment in the code ?

The rest of the patch looks good to me.

Reviewed-by Gautham R. Shenoy <[email protected]>

--
Thanks and Regards
gautham.

Quoted 106 lines

(quoted diff) +0 -0

  	return 0;
  }

drivers/cpufreq/amd-pstate.c +13 -21

index f470b5700db58..ec32c830abc1d 100644
@@ -807,32 +807,18 @@ static DECLARE_WORK(sched_prefcore_work, amd_pstste_sched_prefcore_workfn);
 
  static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata)
  {
-	int ret, prio;
-	u32 highest_perf;
-
-	ret = amd_get_highest_perf(cpudata->cpu, &highest_perf);
-	if (ret)
+	/* user disabled or not detected */
+	if (!amd_pstate_prefcore)
  		return;
 
  	cpudata->hw_prefcore = true;
-	/* check if CPPC preferred core feature is enabled*/
-	if (highest_perf < CPPC_MAX_PERF)
-		prio = (int)highest_perf;
-	else {
-		pr_debug("AMD CPPC preferred core is unsupported!\n");
-		cpudata->hw_prefcore = false;
-		return;
-	}
-
-	if (!amd_pstate_prefcore)
-		return;
 
  	/*
  	 * The priorities can be set regardless of whether or not
  	 * sched_set_itmt_support(true) has been called and it is valid to
  	 * update them at any time after it has been called.
  	 */
-	sched_set_itmt_core_prio(prio, cpudata->cpu);
+	sched_set_itmt_core_prio((int)READ_ONCE(cpudata->highest_perf), cpudata->cpu);
 
  	schedule_work(&sched_prefcore_work);
  }

@@ -998,12 +984,12 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
 
  	cpudata->cpu = policy->cpu;
 
-	amd_pstate_init_prefcore(cpudata);
-
  	ret = amd_pstate_init_perf(cpudata);
  	if (ret)
  		goto free_cpudata1;
 
+	amd_pstate_init_prefcore(cpudata);
+
  	ret = amd_pstate_init_freq(cpudata);
  	if (ret)
  		goto free_cpudata1;

@@ -1453,12 +1439,12 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
  	cpudata->cpu = policy->cpu;
  	cpudata->epp_policy = 0;
 
-	amd_pstate_init_prefcore(cpudata);
-
  	ret = amd_pstate_init_perf(cpudata);
  	if (ret)
  		goto free_cpudata1;
 
+	amd_pstate_init_prefcore(cpudata);
+
  	ret = amd_pstate_init_freq(cpudata);
  	if (ret)
  		goto free_cpudata1;

@@ -1903,6 +1889,12 @@ static int __init amd_pstate_init(void)
  		static_call_update(amd_pstate_update_perf, cppc_update_perf);
  	}
 
+	if (amd_pstate_prefcore) {
+		ret = amd_detect_prefcore(&amd_pstate_prefcore);
+		if (ret)
+			return ret;
+	}
+
  	/* enable amd pstate feature */
  	ret = amd_pstate_enable(true);
  	if (ret) {

include/acpi/cppc_acpi.h +2 -0

index 2246ce0630362..1d79320a23490 100644
@@ -137,10 +137,12 @@ struct cppc_cpudata {
  };
 
  #ifdef CONFIG_CPU_SUP_AMD
+extern int amd_detect_prefcore(bool *detected);
  extern int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf);
  extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator);
  #else /* !CONFIG_CPU_SUP_AMD */
  static inline int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf) { return -ENODEV; }
+static inline int amd_detect_prefcore(bool *detected) { return -ENODEV; }
  static inline int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator) { return -ENODEV; }
  #endif /* !CONFIG_CPU_SUP_AMD */
 

Signature · 1 line

2.43.0

From: Mario Limonciello <[email protected]>

The special case in amd_pstate_highest_perf_set() is the value used for calculating the boost numerator. Merge this into amd_get_boost_ratio_numerator() and then use that to calculate boost ratio.

This allows dropping more special casing of the highest perf value.

Signed-off-by Mario Limonciello <[email protected]>

---
 arch/x86/kernel/acpi/cppc.c  | 16 ++++++++++++
 drivers/cpufreq/amd-pstate.c | 49 +++++++-----------------------------
 2 files changed, 25 insertions(+), 40 deletions(-)

arch/x86/kernel/acpi/cppc.c +16 -0

index 729b35e84f5eb..44b13a4e28740 100644
@@ -9,6 +9,7 @@
 #include <asm/processor.h>
 #include <asm/topology.h>
 
+#define CPPC_HIGHEST_PERF_PERFORMANCE	196
 #define CPPC_HIGHEST_PERF_PREFCORE	166
 
 enum amd_pref_core {

@@ -244,6 +245,21 @@ int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
 		*numerator = boost_numerator;
 		return 0;
 	}
+
+	/*
+	 * For AMD CPUs with Family ID 19H and Model ID range 0x70 to 0x7f,
+	 * the highest performance level is set to 196.
+	 * https://bugzilla.kernel.org/show_bug.cgi?id=218759
+	 */
+	if (cpu_feature_enabled(X86_FEATURE_ZEN4)) {
+		switch (boot_cpu_data.x86_model) {
+		case 0x70 ... 0x7f:
+			*numerator = CPPC_HIGHEST_PERF_PERFORMANCE;
+			return 0;
+		default:
+			break;
+		}
+	}
 	*numerator = CPPC_HIGHEST_PERF_PREFCORE;
 
 	return 0;

drivers/cpufreq/amd-pstate.c +0 -22

index ec32c830abc1d..75568d0f84623 100644
@@ -52,8 +52,6 @@
 #define AMD_PSTATE_TRANSITION_LATENCY	20000
 #define AMD_PSTATE_TRANSITION_DELAY	1000
 #define AMD_PSTATE_FAST_CPPC_TRANSITION_DELAY 600
-#define CPPC_HIGHEST_PERF_PERFORMANCE	196
-#define CPPC_HIGHEST_PERF_DEFAULT	166
 
 #define AMD_CPPC_EPP_PERFORMANCE		0x00
 #define AMD_CPPC_EPP_BALANCE_PERFORMANCE	0x80

@@ -372,43 +370,17 @@ static inline int amd_pstate_enable(bool enable)
 	return static_call(amd_pstate_enable)(enable);
 }
 
-static u32 amd_pstate_highest_perf_set(struct amd_cpudata *cpudata)
-{
-	struct cpuinfo_x86 *c = &cpu_data(0);
-
-	/*
-	 * For AMD CPUs with Family ID 19H and Model ID range 0x70 to 0x7f,
-	 * the highest performance level is set to 196.
-	 * https://bugzilla.kernel.org/show_bug.cgi?id=218759
-	 */
-	if (c->x86 == 0x19 && (c->x86_model >= 0x70 && c->x86_model <= 0x7f))
-		return CPPC_HIGHEST_PERF_PERFORMANCE;
-
-	return CPPC_HIGHEST_PERF_DEFAULT;
-}
-
 static int pstate_init_perf(struct amd_cpudata *cpudata)
 {
 	u64 cap1;
-	u32 highest_perf;
 
 	int ret = rdmsrl_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
 				     &cap1);
 	if (ret)
 		return ret;
 
-	/* For platforms that do not support the preferred core feature, the
-	 * highest_pef may be configured with 166 or 255, to avoid max frequency
-	 * calculated wrongly. we take the AMD_CPPC_HIGHEST_PERF(cap1) value as
-	 * the default max perf.

Hello Mario,

Quoted 95 lines · Mario Limonciello

From: Mario Limonciello <[email protected]>

The special case in amd_pstate_highest_perf_set() is the value used for calculating the boost numerator. Merge this into amd_get_boost_ratio_numerator() and then use that to calculate boost ratio.

This allows dropping more special casing of the highest perf value.

Signed-off-by Mario Limonciello <[email protected]>

---
  arch/x86/kernel/acpi/cppc.c  | 16 ++++++++++++
  drivers/cpufreq/amd-pstate.c | 49 +++++++-----------------------------
  2 files changed, 25 insertions(+), 40 deletions(-)

arch/x86/kernel/acpi/cppc.c +16 -0

index 729b35e84f5eb..44b13a4e28740 100644
@@ -9,6 +9,7 @@
  #include <asm/processor.h>
  #include <asm/topology.h>
 
+#define CPPC_HIGHEST_PERF_PERFORMANCE	196
  #define CPPC_HIGHEST_PERF_PREFCORE	166
 
  enum amd_pref_core {

@@ -244,6 +245,21 @@ int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
  		*numerator = boost_numerator;
  		return 0;
  	}
+
+	/*
+	 * For AMD CPUs with Family ID 19H and Model ID range 0x70 to 0x7f,
+	 * the highest performance level is set to 196.
+	 * https://bugzilla.kernel.org/show_bug.cgi?id=218759
+	 */
+	if (cpu_feature_enabled(X86_FEATURE_ZEN4)) {
+		switch (boot_cpu_data.x86_model) {
+		case 0x70 ... 0x7f:
+			*numerator = CPPC_HIGHEST_PERF_PERFORMANCE;
+			return 0;
+		default:
+			break;
+		}
+	}
  	*numerator = CPPC_HIGHEST_PERF_PREFCORE;
 
  	return 0;

drivers/cpufreq/amd-pstate.c +0 -22

index ec32c830abc1d..75568d0f84623 100644
@@ -52,8 +52,6 @@
  #define AMD_PSTATE_TRANSITION_LATENCY	20000
  #define AMD_PSTATE_TRANSITION_DELAY	1000
  #define AMD_PSTATE_FAST_CPPC_TRANSITION_DELAY 600
-#define CPPC_HIGHEST_PERF_PERFORMANCE	196
-#define CPPC_HIGHEST_PERF_DEFAULT	166
 
  #define AMD_CPPC_EPP_PERFORMANCE		0x00
  #define AMD_CPPC_EPP_BALANCE_PERFORMANCE	0x80

@@ -372,43 +370,17 @@ static inline int amd_pstate_enable(bool enable)
  	return static_call(amd_pstate_enable)(enable);
  }
 
-static u32 amd_pstate_highest_perf_set(struct amd_cpudata *cpudata)
-{
-	struct cpuinfo_x86 *c = &cpu_data(0);
-
-	/*
-	 * For AMD CPUs with Family ID 19H and Model ID range 0x70 to 0x7f,
-	 * the highest performance level is set to 196.
-	 * https://bugzilla.kernel.org/show_bug.cgi?id=218759
-	 */
-	if (c->x86 == 0x19 && (c->x86_model >= 0x70 && c->x86_model <= 0x7f))
-		return CPPC_HIGHEST_PERF_PERFORMANCE;
-
-	return CPPC_HIGHEST_PERF_DEFAULT;
-}
-
  static int pstate_init_perf(struct amd_cpudata *cpudata)
  {
  	u64 cap1;
-	u32 highest_perf;
 
  	int ret = rdmsrl_safe_on_cpu(cpudata->cpu, MSR_AMD_CPPC_CAP1,
  				     &cap1);
  	if (ret)
  		return ret;
 
-	/* For platforms that do not support the preferred core feature, the
-	 * highest_pef may be configured with 166 or 255, to avoid max frequency
-	 * calculated wrongly. we take the AMD_CPPC_HIGHEST_PERF(cap1) value as
-	 * the default max perf.

drivers/cpufreq/amd-pstate.c static inline int amd_pstate_enable(bool enable) · line 383

Quoted 10 lines

drivers/cpufreq/amd-pstate.c +2 -8

-	 */
-	if (cpudata->hw_prefcore)
-		highest_perf = amd_pstate_highest_perf_set(cpudata);
-	else
-		highest_perf = AMD_CPPC_HIGHEST_PERF(cap1);
-
-	WRITE_ONCE(cpudata->highest_perf, highest_perf);
-	WRITE_ONCE(cpudata->max_limit_perf, highest_perf);
+	WRITE_ONCE(cpudata->highest_perf, AMD_CPPC_HIGHEST_PERF(cap1));
+	WRITE_ONCE(cpudata->max_limit_perf, AMD_CPPC_HIGHEST_PERF(cap1));

So henceforth, cpudata->highest_perf is expected to cache the value of CPPC.highest_perf and not the boost_ratio_numerator. There are couple of user-visible changes due to this.

1. On platforms where preferred-core is supported, previously the sysfs file /sys/devices/system/cpu/cpuX/cpufreq/amd_pstate_highest_perf would report the boost_ratio_numerator. Henceforth it will report CPPC.highest_perf.

I hope there are no userspace tools that compute the boost_ratio using the syfs amd_pstate_highest_perf/amd_pstate_nominal_perf.

2. The amd_pstate_prefcore_ranking and amd_pstate_highest_perf will show the same values on all platforms, and henceforth are redundant.

Shouldn't this be documented?

The rest of the patch looks good to me.

--
Thanks and Regards
gautham.

On 8/27/2024 11:52, Gautham R. Shenoy wrote:

Quoted 7 lines

So henceforth, cpudata->highest_perf is expected to cache the value of CPPC.highest_perf and not the boost_ratio_numerator. There are couple of user-visible changes due to this.

Quoted 5 lines

1. On platforms where preferred-core is supported, previously the sysfs file /sys/devices/system/cpu/cpuX/cpufreq/amd_pstate_highest_perf would report the boost_ratio_numerator. Henceforth it will report CPPC.highest_perf.

Quoted 8 lines

I hope there are no userspace tools that compute the boost_ratio using the syfs amd_pstate_highest_perf/amd_pstate_nominal_perf.

2. The amd_pstate_prefcore_ranking and amd_pstate_highest_perf will show the same values on all platforms, and henceforth are redundant.

Good observations here. I'm not aware of any tools trying to replicate this calculation.
With the redundancy I would actually argue we should just drop the sysfs file 'amd_pstate_prefcore_ranking'.

Thoughts?

Quoted 3 lines

Shouldn't this be documented?

I noticed amd_pstate_prefcore_ranking wasn't properly documented in amd-pstate.rst in the first place. If the decision is not to drop the sysfs file, then I'll add a section for it.

Quoted 6 lines

The rest of the patch looks good to me.

-----Original Message-----
From: Mario Limonciello <[email protected]>
Sent: Tuesday, August 27, 2024 5:14 AM
To: Borislav Petkov <[email protected]>; Shenoy, Gautham Ranjal <[email protected]>; Yuan, Perry <[email protected]>
Cc: maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; Rafael J . Wysocki <[email protected]>; open list:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; open list:ACPI <linux- [email protected]>; open list:CPU FREQUENCY SCALING FRAMEWORK <[email protected]>; Limonciello, Mario <[email protected]>
Subject: [PATCH 7/8] cpufreq: amd-pstate: Optimize amd_pstate_update_limits()

From: Mario Limonciello <[email protected]>

Don't take and release the mutex when prefcore isn't present and avoid initialization of variables that will be initially set in the function.

Signed-off-by Mario Limonciello <[email protected]>

---
 drivers/cpufreq/amd-pstate.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/cpufreq/amd-pstate.c +5 -5

index 75568d0f84623..ed05d7a0add10 100644
@@ -798,17 +798,17 @@ static void amd_pstate_update_limits(unsigned int
 cpu)
      int ret;
      bool highest_perf_changed = false;
 
-     mutex_lock(&amd_pstate_driver_lock);
-     if ((!amd_pstate_prefcore) || (!cpudata->hw_prefcore))
-             goto free_cpufreq_put;
+     if (!amd_pstate_prefcore)
+             return;
 
+     mutex_lock(&amd_pstate_driver_lock);
      ret = amd_get_highest_perf(cpu, &cur_high);
      if (ret)
              goto free_cpufreq_put;
 
      prev_high = READ_ONCE(cpudata->prefcore_ranking);
-     if (prev_high != cur_high) {
-             highest_perf_changed = true;
+     highest_perf_changed = (prev_high != cur_high);
+     if (highest_perf_changed) {
              WRITE_ONCE(cpudata->prefcore_ranking, cur_high);
 

if (cur_high < CPPC_MAX_PERF)
--
2.43.0

From: Mario Limonciello <[email protected]>

Don't take and release the mutex when prefcore isn't present and avoid initialization of variables that will be initially set in the function.

Signed-off-by Mario Limonciello <[email protected]>

---
 drivers/cpufreq/amd-pstate.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/cpufreq/amd-pstate.c +0 -0

index 75568d0f84623..ed05d7a0add10 100644

Quoted 17 lines · Mario Limonciello

From: Mario Limonciello <[email protected]>

Don't take and release the mutex when prefcore isn't present and avoid initialization of variables that will be initially set in the function.

Signed-off-by Mario Limonciello <[email protected]>

---
  drivers/cpufreq/amd-pstate.c | 10 +++++-----
  1 file changed, 5 insertions(+), 5 deletions(-)

drivers/cpufreq/amd-pstate.c +0 -0

index 75568d0f84623..ed05d7a0add10 100644

drivers/cpufreq/amd-pstate.c static void amd_pstate_update_limits(unsigned int cpu) · line 802

Quoted 8 lines

drivers/cpufreq/amd-pstate.c +2 -3

@@ -798,17 +798,17 @@ static void amd_pstate_update_limits(unsigned int cpu)
  	int ret;
  	bool highest_perf_changed = false;
 
-	mutex_lock(&amd_pstate_driver_lock);
-	if ((!amd_pstate_prefcore) || (!cpudata->hw_prefcore))
-		goto free_cpufreq_put;
+	if (!amd_pstate_prefcore)
+		return;

Looks good to me.

Wondering if it is worth maintaining a static key for amd_pstate_prefcore. Anyway it doesn't change after boot.

Reviewed-by Gautham R. Shenoy <[email protected]>

--
Thanks and Regards
gautham.

-----Original Message-----
From: Mario Limonciello <[email protected]>
Sent: Tuesday, August 27, 2024 5:14 AM
To: Borislav Petkov <[email protected]>; Shenoy, Gautham Ranjal <[email protected]>; Yuan, Perry <[email protected]>
Cc: maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; Rafael J . Wysocki <[email protected]>; open list:X86 ARCHITECTURE (32-BIT AND 64-BIT) <[email protected]>; open list:ACPI <linux- [email protected]>; open list:CPU FREQUENCY SCALING FRAMEWORK <[email protected]>; Limonciello, Mario <[email protected]>
Subject: [PATCH 8/8] cpufreq: amd-pstate: Drop some uses of cpudata-

Quoted 1 line

hw_prefcore

From: Mario Limonciello <[email protected]>

As the global variable is cleared when preferred cores is not present the local variable use isn't needed in many functions.
Drop it where possible. No intended functional changes.

Signed-off-by Mario Limonciello <[email protected]>

---
 drivers/cpufreq/amd-pstate.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

drivers/cpufreq/amd-pstate.c +0 -0

index ed05d7a0add10..257e28e549bd1 100644
@@ -1112,12 +1112,7 @@ static ssize_t

show_amd_pstate_prefcore_ranking(struct cpufreq_policy *policy, static ssize_t show_amd_pstate_hw_prefcore(struct cpufreq_policy *policy,
char *buf)
{

drivers/cpufreq/amd-pstate.c +2 -7

-     bool hw_prefcore;
-     struct amd_cpudata *cpudata = policy->driver_data;
-
-     hw_prefcore = READ_ONCE(cpudata->hw_prefcore);
-
-     return sysfs_emit(buf, "%s\n", str_enabled_disabled(hw_prefcore));
+     return sysfs_emit(buf, "%s\n",
+str_enabled_disabled(amd_pstate_prefcore));
 }
 
 static ssize_t show_energy_performance_available_preferences(
--

2.43.0

From: Mario Limonciello <[email protected]>

As the global variable is cleared when preferred cores is not present the local variable use isn't needed in many functions. Drop it where possible. No intended functional changes.

Signed-off-by Mario Limonciello <[email protected]>

---
 drivers/cpufreq/amd-pstate.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

drivers/cpufreq/amd-pstate.c +0 -0

index ed05d7a0add10..257e28e549bd1 100644

drivers/cpufreq/amd-pstate.c +0 -0

 }
 
 static ssize_t show_energy_performance_available_preferences(

Signature · 1 line

2.43.0

Quoted 23 lines · Mario Limonciello

From: Mario Limonciello <[email protected]>

As the global variable is cleared when preferred cores is not present the local variable use isn't needed in many functions. Drop it where possible. No intended functional changes.

Signed-off-by Mario Limonciello <[email protected]>

---
  drivers/cpufreq/amd-pstate.c | 7 +------
  1 file changed, 1 insertion(+), 6 deletions(-)

drivers/cpufreq/amd-pstate.c +0 -4

index ed05d7a0add10..257e28e549bd1 100644
@@ -1112,12 +1112,7 @@ static ssize_t show_amd_pstate_prefcore_ranking(struct cpufreq_policy *policy,
  static ssize_t show_amd_pstate_hw_prefcore(struct cpufreq_policy *policy,
  					   char *buf)
  {
-	bool hw_prefcore;
-	struct amd_cpudata *cpudata = policy->driver_data;
-
-	hw_prefcore = READ_ONCE(cpudata->hw_prefcore);

drivers/cpufreq/amd-pstate.c static ssize_t show_amd_pstate_prefcore_ranking(struct cpufreq_policy *policy, · line 1115

Quoted 3 lines

drivers/cpufreq/amd-pstate.c +1 -2

-
-	return sysfs_emit(buf, "%s\n", str_enabled_disabled(hw_prefcore));
+	return sysfs_emit(buf, "%s\n", str_enabled_disabled(amd_pstate_prefcore));

If the user boots with "amd_prefcore=disable" on a system that supports preferred-core, pror to this patchset, cpudata->hw_prefcore would be true and thus, amd_pstate_hw_prefcore would show "enabled".

With this patchset, it would show "disabled". Or am I missing something?

Quoted 9 lines

drivers/cpufreq/amd-pstate.c +0 -0

  }
 
  static ssize_t show_energy_performance_available_preferences(

Signature · 1 line

2.43.0

--
Thanks and Regards
gautham.

Quoted 24 lines · Gautham R. Shenoy

Quoted 23 lines · Mario Limonciello

From: Mario Limonciello <[email protected]>

As the global variable is cleared when preferred cores is not present the local variable use isn't needed in many functions. Drop it where possible. No intended functional changes.

Signed-off-by Mario Limonciello <[email protected]>

---
  drivers/cpufreq/amd-pstate.c | 7 +------
  1 file changed, 1 insertion(+), 6 deletions(-)

drivers/cpufreq/amd-pstate.c +0 -4

index ed05d7a0add10..257e28e549bd1 100644
@@ -1112,12 +1112,7 @@ static ssize_t show_amd_pstate_prefcore_ranking(struct cpufreq_policy *policy,
  static ssize_t show_amd_pstate_hw_prefcore(struct cpufreq_policy *policy,
  					   char *buf)
  {
-	bool hw_prefcore;
-	struct amd_cpudata *cpudata = policy->driver_data;
-
-	hw_prefcore = READ_ONCE(cpudata->hw_prefcore);

Quoted 9 lines

drivers/cpufreq/amd-pstate.c static ssize_t show_amd_pstate_prefcore_ranking(struct cpufreq_policy *policy, · line 1115

Quoted 3 lines

drivers/cpufreq/amd-pstate.c +1 -2

-
-	return sysfs_emit(buf, "%s\n", str_enabled_disabled(hw_prefcore));
+	return sysfs_emit(buf, "%s\n", str_enabled_disabled(amd_pstate_prefcore));

If the user boots with "amd_prefcore=disable" on a system that supports preferred-core, pror to this patchset, cpudata->hw_prefcore would be true and thus, amd_pstate_hw_prefcore would show "enabled".

Yes; you're right about the previous behavior.

Quoted 1 line

With this patchset, it would show "disabled". Or am I missing something?

This appears to be another case we don't have documentation for the sysfs file amd_pstate_hw_prefcore.

I had thought this was a malfunction in the behavior that it reflected the current status, not the hardware /capability/.

Which one makes more sense for userspace? In my mind the most likely consumer of this information would be something a sched_ext based userspace scheduler. They would need to know whether the scheduler was using preferred cores; not whether the hardware supported it.

Whichever direction we agree to go; I'll add documentation for v2.

Quoted 7 lines

I had thought this was a malfunction in the behavior that it reflected the current status, not the hardware /capability/.

Which one makes more sense for userspace? In my mind the most likely consumer of this information would be something a sched_ext based userspace scheduler. They would need to know whether the scheduler was using preferred cores; not whether the hardware supported it.

The commandline parameter currently impacts only the fair sched-class tasks since the preference information gets used only during load-balancing.

IMO, the same should continue with sched-ext, i.e. if the user has explicitly disabled prefcore support via commandline, the no sched-ext scheduler should use the preference information to make task placement decisions. However, I would like to see what the sched-ext folks have to say. Adding some of them to the Cc list.

On Wed, Aug 28, 2024 at 10:38:45AM +0530, Gautham R. Shenoy wrote:
...

Quoted 12 lines

Quoted 7 lines

I had thought this was a malfunction in the behavior that it reflected the current status, not the hardware /capability/.

Which one makes more sense for userspace? In my mind the most likely consumer of this information would be something a sched_ext based userspace scheduler. They would need to know whether the scheduler was using preferred cores; not whether the hardware supported it.

The commandline parameter currently impacts only the fair sched-class tasks since the preference information gets used only during load-balancing.

Quoted 5 lines

IMO, the same should continue with sched-ext, i.e. if the user has explicitly disabled prefcore support via commandline, the no sched-ext scheduler should use the preference information to make task placement decisions. However, I would like to see what the sched-ext folks have to say. Adding some of them to the Cc list.

IMHO it makes more sense to reflect the real state of prefcore support from a "system" perspective, more than a "hardware" perspective, so if it's disabled via boot command line it should show disabled.

From a user-space scheduler perspective we should be fine either way, as long as the ABI is clearly documented, since we also have access to /proc/cmdline and we would be able to figure out if the user has disabled it via cmdline (however, the preference is still to report the actual system status).

Question: having prefcore enabled affects also the value of scaling_max_freq? Like an lscpu -e, for example, would show a higher max frequency for the specific preferred cores? (this is another useful information from a sched_ext scheduler perspective).

Thanks,
-Andrea

Hello Andrea,

Quoted 24 lines · Andrea Righi

On Wed, Aug 28, 2024 at 10:38:45AM +0530, Gautham R. Shenoy wrote:
...

Quoted 12 lines

Quoted 7 lines

I had thought this was a malfunction in the behavior that it reflected the current status, not the hardware /capability/.

Which one makes more sense for userspace? In my mind the most likely consumer of this information would be something a sched_ext based userspace scheduler. They would need to know whether the scheduler was using preferred cores; not whether the hardware supported it.

The commandline parameter currently impacts only the fair sched-class tasks since the preference information gets used only during load-balancing.

Quoted 5 lines

IMO, the same should continue with sched-ext, i.e. if the user has explicitly disabled prefcore support via commandline, the no sched-ext scheduler should use the preference information to make task placement decisions. However, I would like to see what the sched-ext folks have to say. Adding some of them to the Cc list.

IMHO it makes more sense to reflect the real state of prefcore support from a "system" perspective, more than a "hardware" perspective, so if it's disabled via boot command line it should show disabled.

Quoted 5 lines

From a user-space scheduler perspective we should be fine either way, as long as the ABI is clearly documented, since we also have access to /proc/cmdline and we would be able to figure out if the user has disabled it via cmdline (however, the preference is still to report the actual system status).

Thank you for confirming this.

Quoted 5 lines

Question: having prefcore enabled affects also the value of scaling_max_freq? Like an lscpu -e, for example, would show a higher max frequency for the specific preferred cores? (this is another useful information from a sched_ext scheduler perspective).

Since the scaling_max_freq is computed based on the boost-numerator, at least from this patchset, the numerator would be the same across all kinds of cores, and thus the scaling_max_freq reported will be the same across all the cores.

Quoted 41 lines · Gautham R. Shenoy

Hello Andrea,

Quoted 24 lines · Andrea Righi

On Wed, Aug 28, 2024 at 10:38:45AM +0530, Gautham R. Shenoy wrote:
...

Quoted 12 lines

Quoted 7 lines

I had thought this was a malfunction in the behavior that it reflected the current status, not the hardware /capability/.

Which one makes more sense for userspace? In my mind the most likely consumer of this information would be something a sched_ext based userspace scheduler. They would need to know whether the scheduler was using preferred cores; not whether the hardware supported it.

The commandline parameter currently impacts only the fair sched-class tasks since the preference information gets used only during load-balancing.

Quoted 5 lines

IMO, the same should continue with sched-ext, i.e. if the user has explicitly disabled prefcore support via commandline, the no sched-ext scheduler should use the preference information to make task placement decisions. However, I would like to see what the sched-ext folks have to say. Adding some of them to the Cc list.

IMHO it makes more sense to reflect the real state of prefcore support from a "system" perspective, more than a "hardware" perspective, so if it's disabled via boot command line it should show disabled.

Quoted 5 lines

From a user-space scheduler perspective we should be fine either way, as
long as the ABI is clearly documented, since we also have access to /proc/cmdline and we would be able to figure out if the user has disabled it via cmdline (however, the preference is still to report the actual system status).

Thank you for confirming this.

Quoted 5 lines

Question: having prefcore enabled affects also the value of scaling_max_freq? Like an lscpu -e, for example, would show a higher max frequency for the specific preferred cores? (this is another useful information from a sched_ext scheduler perspective).

Quoted 4 lines

Since the scaling_max_freq is computed based on the boost-numerator, at least from this patchset, the numerator would be the same across all kinds of cores, and thus the scaling_max_freq reported will be the same across all the cores.

I see, so IIUC from user-space the most reliable way to detect the fastest cores is to check amd_pstate_highest_perf / amd_pstate_max_freq, right? I'm trying to figure out a way to abstract and generalize the concept of "fast cores" in sched_ext.

Also, is this something that has changed recently? I see this on an AMD Ryzen Threadripper PRO 7975WX 32-Cores running a 6.8 kernel:

$ uname -r
6.8.0-40-generic

Quoted 47 lines · Andrea Righi

Quoted 45 lines · Gautham R. Shenoy

Hello Andrea,

Quoted 24 lines · Andrea Righi

On Wed, Aug 28, 2024 at 10:38:45AM +0530, Gautham R. Shenoy wrote:
...

Quoted 12 lines

Quoted 7 lines

I had thought this was a malfunction in the behavior that it reflected the current status, not the hardware /capability/.

Which one makes more sense for userspace? In my mind the most likely consumer of this information would be something a sched_ext based userspace scheduler. They would need to know whether the scheduler was using preferred cores; not whether the hardware supported it.

The commandline parameter currently impacts only the fair sched-class tasks since the preference information gets used only during load-balancing.

Quoted 5 lines

IMO, the same should continue with sched-ext, i.e. if the user has explicitly disabled prefcore support via commandline, the no sched-ext scheduler should use the preference information to make task placement decisions. However, I would like to see what the sched-ext folks have to say. Adding some of them to the Cc list.

IMHO it makes more sense to reflect the real state of prefcore support from a "system" perspective, more than a "hardware" perspective, so if it's disabled via boot command line it should show disabled.

Quoted 5 lines

From a user-space scheduler perspective we should be fine either way, as
long as the ABI is clearly documented, since we also have access to /proc/cmdline and we would be able to figure out if the user has disabled it via cmdline (however, the preference is still to report the actual system status).

Thank you for confirming this.

Quoted 5 lines

Question: having prefcore enabled affects also the value of scaling_max_freq? Like an lscpu -e, for example, would show a higher max frequency for the specific preferred cores? (this is another useful information from a sched_ext scheduler perspective).

Since the scaling_max_freq is computed based on the boost-numerator, at least from this patchset, the numerator would be the same across all kinds of cores, and thus the scaling_max_freq reported will be the same across all the cores.

Quoted 4 lines

I see, so IIUC from user-space the most reliable way to detect the fastest cores is to check amd_pstate_highest_perf / amd_pstate_max_freq, right? I'm trying to figure out a way to abstract and generalize the concept of "fast cores" in sched_ext.

Right now the best way to do this is to look at the amd_pstate_precore_ranking file.

In this series there has been some discussion of dropping it though in favor of looking at the highest perf file. I don't believe we're concluded one way or another on it yet though.

Quoted 1 line

Quoted 5 lines

Also, is this something that has changed recently? I see this on an AMD Ryzen Threadripper PRO 7975WX 32-Cores running a 6.8 kernel:

$ uname -r
6.8.0-40-generic

You're missing the preferred core patches on this kernel. They landed in 6.9, it's better to upgrade to 6.10.y or 6.11-rc.