From: Qais Yousef <qyousef@layalina.io>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Juri Lelli <juri.lelli@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Valentin Schneider <vschneid@redhat.com>
Subject: Re: [GIT PULL] Scheduler changes for v6.8
Date: Sat, 13 Jan 2024 18:33:20 +0000 [thread overview]
Message-ID: <20240113183320.sfm5v35tid55d6sf@airbuntu> (raw)
In-Reply-To: <ZaJqRfjsI820jfXE@vingu-book>
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@linux-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
next prev parent reply other threads:[~2024-01-13 18:33 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-28 12:23 [GIT PULL] Scheduler changes for v6.7 Ingo Molnar
2023-10-30 23:50 ` pr-tracker-bot
2024-01-08 14:07 ` [GIT PULL] Scheduler changes for v6.8 Ingo Molnar
2024-01-09 4:04 ` pr-tracker-bot
2024-01-10 22:19 ` Linus Torvalds
2024-01-10 22:41 ` Linus Torvalds
2024-01-10 22:57 ` Linus Torvalds
2024-01-11 8:11 ` Vincent Guittot
2024-01-11 17:45 ` Linus Torvalds
2024-01-11 17:53 ` Linus Torvalds
2024-01-11 18:16 ` Vincent Guittot
2024-01-12 14:23 ` Dietmar Eggemann
2024-01-12 16:58 ` Vincent Guittot
2024-01-12 18:18 ` Qais Yousef
2024-01-12 19:03 ` Vincent Guittot
2024-01-12 20:30 ` Linus Torvalds
2024-01-12 20:49 ` Linus Torvalds
2024-01-12 21:04 ` Linus Torvalds
2024-01-13 1:04 ` Qais Yousef
2024-01-13 1:24 ` Linus Torvalds
2024-01-13 1:31 ` Linus Torvalds
2024-01-13 10:47 ` Vincent Guittot
2024-01-13 18:33 ` Qais Yousef [this message]
2024-01-13 18:37 ` Qais Yousef
2024-01-11 11:09 ` [GIT PULL] scheduler fixes Ingo Molnar
2024-01-11 13:04 ` Vincent Guittot
2024-01-11 20:48 ` [PATCH] Revert "sched/cpufreq: Rework schedutil governor performance estimation" and dependent commit Ingo Molnar
2024-01-11 22:22 ` Vincent Guittot
2024-01-12 18:24 ` Ingo Molnar
2024-01-12 18:26 ` [GIT PULL] Scheduler changes for v6.8 Ingo Molnar
2024-01-14 9:12 ` Wyes Karny
2024-01-14 11:18 ` Vincent Guittot
2024-01-14 12:37 ` Wyes Karny
2024-01-14 13:02 ` Dietmar Eggemann
2024-01-14 13:05 ` Vincent Guittot
2024-01-14 13:03 ` Vincent Guittot
2024-01-14 15:12 ` Qais Yousef
2024-01-14 15:20 ` Vincent Guittot
2024-01-14 19:58 ` Qais Yousef
2024-01-14 23:37 ` Qais Yousef
2024-01-15 6:25 ` Wyes Karny
2024-01-15 11:59 ` Qais Yousef
2024-01-15 8:21 ` Vincent Guittot
2024-01-15 12:09 ` Qais Yousef
2024-01-15 13:26 ` Vincent Guittot
2024-01-15 14:03 ` Dietmar Eggemann
2024-01-15 15:26 ` Vincent Guittot
2024-01-15 20:05 ` Dietmar Eggemann
2024-01-15 8:42 ` David Laight
2024-01-14 18:11 ` Wyes Karny
2024-01-14 18:18 ` Vincent Guittot
2024-01-11 9:33 ` Ingo Molnar
2024-01-11 11:14 ` [tip: sched/urgent] Revert "sched/cpufreq: Rework schedutil governor performance estimation" and dependent commits tip-bot2 for Ingo Molnar
2024-01-11 20:55 ` [tip: sched/urgent] Revert "sched/cpufreq: Rework schedutil governor performance estimation" and dependent commit tip-bot2 for Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240113183320.sfm5v35tid55d6sf@airbuntu \
--to=qyousef@layalina.io \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.