linux-kernel - Re: [GIT PULL] Scheduler changes for v6.8

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240113183320.sfm5v35tid55d6sf@airbuntu>
Date: Sat, 13 Jan 2024 18:33:20 +0000
From: Qais Yousef <qyousef@...alina.io>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Juri Lelli <juri.lelli@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Daniel Bristot de Oliveira <bristot@...hat.com>,
	Valentin Schneider <vschneid@...hat.com>
Subject: Re: [GIT PULL] Scheduler changes for v6.8

On 01/13/24 11:47, Vincent Guittot wrote:
> Le vendredi 12 janv. 2024 à 17:31:13 (-0800), Linus Torvalds a écrit :
> > On Fri, 12 Jan 2024 at 17:24, Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> > >
> > > With a *working* kernel, I get events, setting the frequency to either
> > > 2.2GHz (idle) or 3.8GHz (work).
> > 
> > Just to fix that - not 3.8Ghz, but in addition to 2.2 I see 2.8 or 3.7:
> 
> IIUC, with the commit you stay at lowest frequency all time which is clearly
> weird. One change that could create such behavior is in
> sugov_effective_cpu_perf() where we take the min between the actual
> utilization and the max allowed. If max is set to min capacity for whatever
> the reason, then you stay stuck to lowest capacity/frequency

I tried on Linus' ToT (052d534373b7) with and without CONFIG_UCLAMP_TASK=y and
I still can't reproduce.

> 
> What is the output of 
> /sys/devices/system/cpu/cpu0/cpu_capacity

Since it's SMP, I don't see these generated.

There's a acpi_cppc node though. For CPU0

	$ grep . /sys/devices/system/cpu/cpu0/acpi_cppc/*
	/sys/devices/system/cpu/cpu0/acpi_cppc/feedback_ctrs:ref:500461208742 del:522909165272
	/sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf:216
	/sys/devices/system/cpu/cpu0/acpi_cppc/lowest_freq:550
	/sys/devices/system/cpu/cpu0/acpi_cppc/lowest_nonlinear_perf:62
	/sys/devices/system/cpu/cpu0/acpi_cppc/lowest_perf:20
	/sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq:3801
	/sys/devices/system/cpu/cpu0/acpi_cppc/nominal_perf:135
	/sys/devices/system/cpu/cpu0/acpi_cppc/reference_perf:135
	/sys/devices/system/cpu/cpu0/acpi_cppc/wraparound_time:18446744073709551615

highest_perf for all CPUs

	$ grep . /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf
	/sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf:216
	/sys/devices/system/cpu/cpu10/acpi_cppc/highest_perf:166
	/sys/devices/system/cpu/cpu11/acpi_cppc/highest_perf:176
	/sys/devices/system/cpu/cpu12/acpi_cppc/highest_perf:216
	/sys/devices/system/cpu/cpu13/acpi_cppc/highest_perf:216
	/sys/devices/system/cpu/cpu14/acpi_cppc/highest_perf:211
	/sys/devices/system/cpu/cpu15/acpi_cppc/highest_perf:206
	/sys/devices/system/cpu/cpu16/acpi_cppc/highest_perf:201
	/sys/devices/system/cpu/cpu17/acpi_cppc/highest_perf:196
	/sys/devices/system/cpu/cpu18/acpi_cppc/highest_perf:191
	/sys/devices/system/cpu/cpu19/acpi_cppc/highest_perf:186
	/sys/devices/system/cpu/cpu1/acpi_cppc/highest_perf:216
	/sys/devices/system/cpu/cpu20/acpi_cppc/highest_perf:181
	/sys/devices/system/cpu/cpu21/acpi_cppc/highest_perf:171
	/sys/devices/system/cpu/cpu22/acpi_cppc/highest_perf:166
	/sys/devices/system/cpu/cpu23/acpi_cppc/highest_perf:176
	/sys/devices/system/cpu/cpu2/acpi_cppc/highest_perf:211
	/sys/devices/system/cpu/cpu3/acpi_cppc/highest_perf:206
	/sys/devices/system/cpu/cpu4/acpi_cppc/highest_perf:201
	/sys/devices/system/cpu/cpu5/acpi_cppc/highest_perf:196
	/sys/devices/system/cpu/cpu6/acpi_cppc/highest_perf:191
	/sys/devices/system/cpu/cpu7/acpi_cppc/highest_perf:186
	/sys/devices/system/cpu/cpu8/acpi_cppc/highest_perf:181
	/sys/devices/system/cpu/cpu9/acpi_cppc/highest_perf:171

Can we overshoot somehow now and hitting a bug in frequency translation in
cpufreq by any chance?

> 
> It should be 1024 or close
> 
> Could you try the below ? it skips this step and ensures to use the actual
> utilization to select the frequency
> 
> ---
>  kernel/sched/cpufreq_schedutil.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 95c3c097083e..e420e2ee1a10 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -181,7 +181,6 @@ unsigned long sugov_effective_cpu_perf(int cpu, unsigned long actual,
>  	/* Add dvfs headroom to actual utilization */
>  	actual = map_util_perf(actual);
>  	/* Actually we don't need to target the max performance */
> -	if (actual < max)
>  		max = actual;
>  
>  	/*
> -- 
> 2.34.1