[LTP] [PATCH v4] device-drivers/cpufreq_boost: Don't hardcode to CPU0

[LTP] [PATCH v4] device-drivers/cpufreq_boost: Don't hardcode to CPU0

[Mike Tipton via ltp]

Some systems don't support boost on every CPU, such as on many Qualcomm
chipsets. And if boost isn't supported on CPU0, then the test will fail
since there's no performance improvement.

Instead of hardcoding CPU0, find the first CPU that belongs to a cpufreq
policy with boost enabled.

Signed-off-by: Mike Tipton <mike.tipton@oss.qualcomm.com>
Acked-by: Wei Gao <wegao@suse.com>
---
Changes in v4:
- Move error handling outside of find_boost_cpu() for improved
  readability.
- Collect Acked-by from Wei.
- Link to v3: https://lore.kernel.org/ltp/20250709151439.2840206-1-mike.tipton@oss.qualcomm.com/

Changes in v3:
- Abort when no CPUs report supporting boost instead of assuming CPU0.
- Link to v2: https://lore.kernel.org/ltp/20250630145128.1254269-1-mike.tipton@oss.qualcomm.com/

Changes in v2:
- Use proper maxspeed buf size in snprintf.
- Link to v1: https://lore.kernel.org/ltp/20250626194707.3053036-1-mike.tipton@oss.qualcomm.com/

 .../device-drivers/cpufreq/cpufreq_boost.c    | 60 ++++++++++++++++---
 1 file changed, 52 insertions(+), 8 deletions(-)

diff --git a/testcases/kernel/device-drivers/cpufreq/cpufreq_boost.c b/testcases/kernel/device-drivers/cpufreq/cpufreq_boost.c
index 67917b3fea25..7aefd8844513 100644
--- a/testcases/kernel/device-drivers/cpufreq/cpufreq_boost.c
+++ b/testcases/kernel/device-drivers/cpufreq/cpufreq_boost.c
@@ -55,10 +55,14 @@ static int id = -1;
 
 static int boost_value;
 
-const char governor[]	= SYSFS_CPU_DIR "cpu0/cpufreq/scaling_governor";
+static int cpu;
+
+static const char _governor[] = SYSFS_CPU_DIR "cpu%d/cpufreq/scaling_governor";
+static char governor[64];
 static char governor_name[16];
 
-const char maxspeed[]	= SYSFS_CPU_DIR "cpu0/cpufreq/scaling_max_freq";
+static const char _maxspeed[] = SYSFS_CPU_DIR "cpu%d/cpufreq/scaling_max_freq";
+static char maxspeed[64];
 
 static void check_set_turbo(char *file, char *off)
 {
@@ -84,6 +88,38 @@ static void cleanup(void)
 		FILE_PRINTF(governor, "%s", governor_name);
 }
 
+static int find_boost_cpu(void)
+{
+	char buf[64];
+	int fd, i;
+
+	/*
+	 * The files we're looking for only exist for acpi_cpufreq. Continue
+	 * assuming CPU0 for intel_pstate.
+	 */
+	if (!strcmp(cdrv[id].name, "intel_pstate"))
+		return 0;
+
+	for (i = 0;; i++) {
+		snprintf(buf, sizeof(buf), SYSFS_CPU_DIR "cpu%d", i);
+		fd = open(buf, O_RDONLY);
+		if (fd == -1)
+			break;
+
+		close(fd);
+
+		snprintf(buf, sizeof(buf), SYSFS_CPU_DIR "cpu%d/cpufreq/boost", i);
+		fd = open(buf, O_RDONLY);
+		if (fd == -1)
+			continue;
+
+		close(fd);
+		return i;
+	}
+
+	return -1;
+}
+
 static void setup(void)
 {
 	int fd;
@@ -109,6 +145,14 @@ static void setup(void)
 	tst_resm(TINFO, "found '%s' driver, sysfs knob '%s'",
 		cdrv[id].name, cdrv[id].file);
 
+	cpu = find_boost_cpu();
+	if (cpu == -1)
+		tst_brkm(TCONF, NULL, "boost not supported by any CPUs");
+
+	tst_resm(TINFO, "found boost-capable CPU (CPU%d)", cpu);
+	snprintf(governor, sizeof(governor), _governor, cpu);
+	snprintf(maxspeed, sizeof(maxspeed), _maxspeed, cpu);
+
 	tst_sig(FORK, DEF_HANDLER, cleanup);
 
 	SAFE_FILE_SCANF(NULL, cdrv[i].file, "%d", &boost_value);
@@ -120,16 +164,16 @@ static void setup(void)
 	if (!strcmp(cdrv[i].name, "intel_pstate") && boost_value == cdrv[i].off)
 		check_set_turbo(cdrv[i].file, cdrv[i].off_str);
 
-	/* change cpu0 scaling governor */
+	/* change cpu scaling governor */
 	SAFE_FILE_SCANF(NULL, governor, "%s", governor_name);
 	SAFE_FILE_PRINTF(cleanup, governor, "%s", "performance");
 
-	/* use only cpu0 */
+	/* use only a single cpu */
 	cpu_set_t set;
 	CPU_ZERO(&set);
-	CPU_SET(0, &set);
+	CPU_SET(cpu, &set);
 	if (sched_setaffinity(0, sizeof(cpu_set_t), &set) < 0)
-		tst_brkm(TBROK | TERRNO, cleanup, "failed to set CPU0");
+		tst_brkm(TBROK | TERRNO, cleanup, "failed to set CPU%d", cpu);
 
 	struct sched_param params;
 	params.sched_priority = sched_get_priority_max(SCHED_FIFO);
@@ -176,12 +220,12 @@ static void test_run(void)
 	/* Enable boost */
 	if (boost_value == cdrv[id].off)
 		SAFE_FILE_PRINTF(cleanup, cdrv[id].file, "%s", cdrv[id].on_str);
-	tst_resm(TINFO, "load CPU0 with boost enabled");
+	tst_resm(TINFO, "load CPU%d with boost enabled", cpu);
 	boost_time = load_cpu(max_freq_khz);
 
 	/* Disable boost */
 	SAFE_FILE_PRINTF(cleanup, cdrv[id].file, "%s", cdrv[id].off_str);
-	tst_resm(TINFO, "load CPU0 with boost disabled");
+	tst_resm(TINFO, "load CPU%d with boost disabled", cpu);
 	boost_off_time = load_cpu(max_freq_khz);
 
 	boost_off_time *= .98;
-- 
2.34.1


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v4] device-drivers/cpufreq_boost: Don't hardcode to CPU0

[Mike Tipton via ltp]

On Thu, Jul 10, 2025 at 10:02:55AM -0700, Mike Tipton wrote:
> Some systems don't support boost on every CPU, such as on many Qualcomm
> chipsets. And if boost isn't supported on CPU0, then the test will fail
> since there's no performance improvement.
> 
> Instead of hardcoding CPU0, find the first CPU that belongs to a cpufreq
> policy with boost enabled.
> 
> Signed-off-by: Mike Tipton <mike.tipton@oss.qualcomm.com>
> Acked-by: Wei Gao <wegao@suse.com>
> ---
> Changes in v4:
> - Move error handling outside of find_boost_cpu() for improved
>   readability.
> - Collect Acked-by from Wei.
> - Link to v3: https://lore.kernel.org/ltp/20250709151439.2840206-1-mike.tipton@oss.qualcomm.com/
> 
> Changes in v3:
> - Abort when no CPUs report supporting boost instead of assuming CPU0.
> - Link to v2: https://lore.kernel.org/ltp/20250630145128.1254269-1-mike.tipton@oss.qualcomm.com/
> 
> Changes in v2:
> - Use proper maxspeed buf size in snprintf.
> - Link to v1: https://lore.kernel.org/ltp/20250626194707.3053036-1-mike.tipton@oss.qualcomm.com/
> 
>  .../device-drivers/cpufreq/cpufreq_boost.c    | 60 ++++++++++++++++---
>  1 file changed, 52 insertions(+), 8 deletions(-)

Hi Cyril / everyone,

Is anything else needed before this patch can be applied?

Thanks,
Mike

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v4] device-drivers/cpufreq_boost: Don't hardcode to CPU0

[Cyril Hrubis]

Hi!
> -const char governor[]	= SYSFS_CPU_DIR "cpu0/cpufreq/scaling_governor";
> +static int cpu;
> +
> +static const char _governor[] = SYSFS_CPU_DIR "cpu%d/cpufreq/scaling_governor";

Identifiers starting with underscore are reserved for kernel/libc
implementation we shouldn't use them here. I guess that this would be
better as governor_fmt.

> +static char governor[64];
>  static char governor_name[16];
>  
> -const char maxspeed[]	= SYSFS_CPU_DIR "cpu0/cpufreq/scaling_max_freq";
> +static const char _maxspeed[] = SYSFS_CPU_DIR "cpu%d/cpufreq/scaling_max_freq";

Here as well.


Other than that it looks fine. I can push the patch with the change from
_governor to governor_fmt and _maxspeed to maxspeed_fmt if you agree.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v4] device-drivers/cpufreq_boost: Don't hardcode to CPU0

[Mike Tipton via ltp]

On Fri, Jul 25, 2025 at 02:31:02PM +0200, Cyril Hrubis wrote:
> Hi!
> > -const char governor[]	= SYSFS_CPU_DIR "cpu0/cpufreq/scaling_governor";
> > +static int cpu;
> > +
> > +static const char _governor[] = SYSFS_CPU_DIR "cpu%d/cpufreq/scaling_governor";
> 
> Identifiers starting with underscore are reserved for kernel/libc
> implementation we shouldn't use them here. I guess that this would be
> better as governor_fmt.
> 
> > +static char governor[64];
> >  static char governor_name[16];
> >  
> > -const char maxspeed[]	= SYSFS_CPU_DIR "cpu0/cpufreq/scaling_max_freq";
> > +static const char _maxspeed[] = SYSFS_CPU_DIR "cpu%d/cpufreq/scaling_max_freq";
> 
> Here as well.
> 
> 
> Other than that it looks fine. I can push the patch with the change from
> _governor to governor_fmt and _maxspeed to maxspeed_fmt if you agree.

Sure, sounds good to me.

Thanks!
Mike

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v4] device-drivers/cpufreq_boost: Don't hardcode to CPU0

[Cyril Hrubis]

Hi!
> Sure, sounds good to me.

Applied, thanks.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp