From: Bruno Goncalves <hidden> Date: 2021-07-29 12:37:12
On Wed, Jul 28, 2021 at 5:55 PM Dietmar Eggemann
[off-list ref] wrote:
On 28/07/2021 15:11, Bruno Goncalves wrote:
quoted
Hello,
Since this commit (Commit: 45312bd762d3 - Merge tag 'zonefs-5.14-rc2')
we started to see the following call trace, it seems to be
reproducible only on aarch64.
It should happen on platforms using a slow-switching cpufreq driver.
Only in this case you have n (depends on nbr of frequency domains)
special-purpose DL threads when using schedutil CPUFreq governor:
root@juno: ps -eTo comm,pid,pri,class | grep sugov
sugov:0 132 140 DLN
sugov:1 134 140 DLN
Don't quite get this.
`sugov:112` should be a special DL entity (dl_se->flags &
SCHED_FLAG_SUGOV) so sub_running_bw() should not call __sub_running_bw()
and hence there won't be a call to cpufreq_update_util() which calls
q_clock(rq) -> assert_clock_updated()?
Can't reproduce it on my Juno (arm64) (slow-switching (scpi-cpufreq
driver)).
We seem to be able to reproduce this only on Ampere Altra machines,
specifically on mtjade and mtsnow cpus.
# cpupower frequency-info
analyzing CPU 0:
driver: cppc_cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 1000 MHz - 2.80 GHz
available cpufreq governors: conservative ondemand userspace
powersave performance schedutil
current policy: frequency should be within 2.00 GHz and 2.80 GHz.
The governor "schedutil" may decide which speed to use
within this range.
current CPU frequency: 1.55 GHz (asserted by call to hardware)
# ps -eTo comm,pid,pri,class | grep sugov
sugov:0 1082 140 DLN
sugov:1 1085 140 DLN
...
sugov:78 1319 140 DLN
sugov:79 1320 140 DLN
Bruno
On Wed, Jul 28, 2021 at 5:55 PM Dietmar Eggemann
[off-list ref] wrote:
quoted
On 28/07/2021 15:11, Bruno Goncalves wrote:
[...]
quoted
Can't reproduce it on my Juno (arm64) (slow-switching (scpi-cpufreq
driver)).
We seem to be able to reproduce this only on Ampere Altra machines,
specifically on mtjade and mtsnow cpus.
# cpupower frequency-info
analyzing CPU 0:
driver: cppc_cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 1000 MHz - 2.80 GHz
available cpufreq governors: conservative ondemand userspace
powersave performance schedutil
current policy: frequency should be within 2.00 GHz and 2.80 GHz.
The governor "schedutil" may decide which speed to use
within this range.
current CPU frequency: 1.55 GHz (asserted by call to hardware)
# ps -eTo comm,pid,pri,class | grep sugov
sugov:0 1082 140 DLN
sugov:1 1085 140 DLN
...
sugov:78 1319 140 DLN
sugov:79 1320 140 DLN
Thanks! In the meantime I got access to an Ampere Altra so I can try
5.14.0-rc1 later today.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jul 28, 2021 at 5:55 PM Dietmar Eggemann
[off-list ref] wrote:
quoted
On 28/07/2021 15:11, Bruno Goncalves wrote:
[...]
quoted
quoted
Can't reproduce it on my Juno (arm64) (slow-switching (scpi-cpufreq
driver)).
We seem to be able to reproduce this only on Ampere Altra machines,
specifically on mtjade and mtsnow cpus.
# cpupower frequency-info
analyzing CPU 0:
driver: cppc_cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 1000 MHz - 2.80 GHz
available cpufreq governors: conservative ondemand userspace
powersave performance schedutil
current policy: frequency should be within 2.00 GHz and 2.80 GHz.
The governor "schedutil" may decide which speed to use
within this range.
current CPU frequency: 1.55 GHz (asserted by call to hardware)
# ps -eTo comm,pid,pri,class | grep sugov
sugov:0 1082 140 DLN
sugov:1 1085 140 DLN
...
sugov:78 1319 140 DLN
sugov:79 1320 140 DLN
Thanks! In the meantime I got access to an Ampere Altra so I can try
5.14.0-rc1 later today.
The task causing this seem to be the new `cppc_fie` DL task introduced
by commit 1eb5dde674f5 "cpufreq: CPPC: Add support for frequency
invariance" in v5.14-rc1.
With `CONFIG_ACPI_CPPC_CPUFREQ_FIE=y` and schedutil cpufreq governor on
slow-switching system:
DL task curr=`sugov:X` makes p=`cppc_fie` migrate and since it is in
`non_contending` state, migrate_task_rq_dl() calls
sub_running_bw()->__sub_running_bw()->cpufreq_update_util()->
rq_clock()->assert_clock_updated()
on p.
Can you try this snippet? It should fix it.
--8<--
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
Date: Fri, 30 Jul 2021 14:03:40 +0200
Subject: [PATCH] sched/deadline: Fix missing clock update in
migrate_task_rq_dl()
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
---
kernel/sched/deadline.c | 1 +
1 file changed, 1 insertion(+)
From: Bruno Goncalves <hidden> Date: 2021-07-30 15:23:32
On Fri, Jul 30, 2021 at 2:22 PM Dietmar Eggemann
[off-list ref] wrote:
On 29/07/2021 16:38, Dietmar Eggemann wrote:
quoted
On 29/07/2021 14:36, Bruno Goncalves wrote:
quoted
On Wed, Jul 28, 2021 at 5:55 PM Dietmar Eggemann
[off-list ref] wrote:
quoted
On 28/07/2021 15:11, Bruno Goncalves wrote:
[...]
quoted
quoted
Can't reproduce it on my Juno (arm64) (slow-switching (scpi-cpufreq
driver)).
We seem to be able to reproduce this only on Ampere Altra machines,
specifically on mtjade and mtsnow cpus.
# cpupower frequency-info
analyzing CPU 0:
driver: cppc_cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 1000 MHz - 2.80 GHz
available cpufreq governors: conservative ondemand userspace
powersave performance schedutil
current policy: frequency should be within 2.00 GHz and 2.80 GHz.
The governor "schedutil" may decide which speed to use
within this range.
current CPU frequency: 1.55 GHz (asserted by call to hardware)
# ps -eTo comm,pid,pri,class | grep sugov
sugov:0 1082 140 DLN
sugov:1 1085 140 DLN
...
sugov:78 1319 140 DLN
sugov:79 1320 140 DLN
Thanks! In the meantime I got access to an Ampere Altra so I can try
5.14.0-rc1 later today.
The task causing this seem to be the new `cppc_fie` DL task introduced
by commit 1eb5dde674f5 "cpufreq: CPPC: Add support for frequency
invariance" in v5.14-rc1.
With `CONFIG_ACPI_CPPC_CPUFREQ_FIE=y` and schedutil cpufreq governor on
slow-switching system:
DL task curr=`sugov:X` makes p=`cppc_fie` migrate and since it is in
`non_contending` state, migrate_task_rq_dl() calls
sub_running_bw()->__sub_running_bw()->cpufreq_update_util()->
rq_clock()->assert_clock_updated()
on p.
Can you try this snippet? It should fix it.
Thank you, I've tried the patch and it fixes the issue.
Bruno
On Fri, Jul 30, 2021 at 2:22 PM Dietmar Eggemann
[off-list ref] wrote:
quoted
On 29/07/2021 16:38, Dietmar Eggemann wrote:
quoted
On 29/07/2021 14:36, Bruno Goncalves wrote:
quoted
On Wed, Jul 28, 2021 at 5:55 PM Dietmar Eggemann
[off-list ref] wrote:
quoted
On 28/07/2021 15:11, Bruno Goncalves wrote:
[...]
quoted
The task causing this seem to be the new `cppc_fie` DL task introduced
by commit 1eb5dde674f5 "cpufreq: CPPC: Add support for frequency
invariance" in v5.14-rc1.
With `CONFIG_ACPI_CPPC_CPUFREQ_FIE=y` and schedutil cpufreq governor on
slow-switching system:
DL task curr=`sugov:X` makes p=`cppc_fie` migrate and since it is in
`non_contending` state, migrate_task_rq_dl() calls
sub_running_bw()->__sub_running_bw()->cpufreq_update_util()->
rq_clock()->assert_clock_updated()
on p.
Can you try this snippet? It should fix it.
Thank you, I've tried the patch and it fixes the issue.