All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruno Goncalves <bgoncalv@redhat.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: CKI Project <cki-project@redhat.com>,
	linux-kernel@vger.kernel.org, nathan@kernel.org,
	Memory Management <mm-qe@redhat.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: WARNING: CPU: 112 PID: 2041 at kernel/sched/sched.h:1453
Date: Fri, 30 Jul 2021 17:23:15 +0200	[thread overview]
Message-ID: <CA+QYu4q3k8d60u5BwLy+mhRFjBd0cukiSmWAXRiMN2SbZ1XavQ@mail.gmail.com> (raw)
In-Reply-To: <1ea2fa5c-ae81-2389-7f02-2227636582e4@arm.com>

On Fri, Jul 30, 2021 at 2:22 PM Dietmar Eggemann
<dietmar.eggemann@arm.com> wrote:
>
> On 29/07/2021 16:38, Dietmar Eggemann wrote:
> > On 29/07/2021 14:36, Bruno Goncalves wrote:
> >> On Wed, Jul 28, 2021 at 5:55 PM Dietmar Eggemann
> >> <dietmar.eggemann@arm.com> wrote:
> >>>
> >>> On 28/07/2021 15:11, Bruno Goncalves wrote:
> >
> > [...]
> >
> >>> 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

>
> --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(+)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index aaacd6cfd42f..4920f498492f 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1733,6 +1733,7 @@ static void migrate_task_rq_dl(struct task_struct *p, int new_cpu __maybe_unused
>          */
>         raw_spin_rq_lock(rq);
>         if (p->dl.dl_non_contending) {
> +               update_rq_clock(rq);
>                 sub_running_bw(&p->dl, &rq->dl);
>                 p->dl.dl_non_contending = 0;
>                 /*
> --
> 2.25.1
>


WARNING: multiple messages have this Message-ID (diff)
From: Bruno Goncalves <bgoncalv@redhat.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: CKI Project <cki-project@redhat.com>,
	linux-kernel@vger.kernel.org, nathan@kernel.org,
	 Memory Management <mm-qe@redhat.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: WARNING: CPU: 112 PID: 2041 at kernel/sched/sched.h:1453
Date: Fri, 30 Jul 2021 17:23:15 +0200	[thread overview]
Message-ID: <CA+QYu4q3k8d60u5BwLy+mhRFjBd0cukiSmWAXRiMN2SbZ1XavQ@mail.gmail.com> (raw)
In-Reply-To: <1ea2fa5c-ae81-2389-7f02-2227636582e4@arm.com>

On Fri, Jul 30, 2021 at 2:22 PM Dietmar Eggemann
<dietmar.eggemann@arm.com> wrote:
>
> On 29/07/2021 16:38, Dietmar Eggemann wrote:
> > On 29/07/2021 14:36, Bruno Goncalves wrote:
> >> On Wed, Jul 28, 2021 at 5:55 PM Dietmar Eggemann
> >> <dietmar.eggemann@arm.com> wrote:
> >>>
> >>> On 28/07/2021 15:11, Bruno Goncalves wrote:
> >
> > [...]
> >
> >>> 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

>
> --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(+)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index aaacd6cfd42f..4920f498492f 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1733,6 +1733,7 @@ static void migrate_task_rq_dl(struct task_struct *p, int new_cpu __maybe_unused
>          */
>         raw_spin_rq_lock(rq);
>         if (p->dl.dl_non_contending) {
> +               update_rq_clock(rq);
>                 sub_running_bw(&p->dl, &rq->dl);
>                 p->dl.dl_non_contending = 0;
>                 /*
> --
> 2.25.1
>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-30 15:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 13:11 WARNING: CPU: 112 PID: 2041 at kernel/sched/sched.h:1453 Bruno Goncalves
2021-07-28 15:55 ` Dietmar Eggemann
2021-07-29 12:36   ` Bruno Goncalves
2021-07-29 12:36     ` Bruno Goncalves
2021-07-29 14:38     ` Dietmar Eggemann
2021-07-29 14:38       ` Dietmar Eggemann
2021-07-30 12:22       ` Dietmar Eggemann
2021-07-30 12:22         ` Dietmar Eggemann
2021-07-30 15:23         ` Bruno Goncalves [this message]
2021-07-30 15:23           ` Bruno Goncalves
2021-08-02  8:43           ` Dietmar Eggemann
2021-08-02  8:43             ` Dietmar Eggemann

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=CA+QYu4q3k8d60u5BwLy+mhRFjBd0cukiSmWAXRiMN2SbZ1XavQ@mail.gmail.com \
    --to=bgoncalv@redhat.com \
    --cc=cki-project@redhat.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mm-qe@redhat.com \
    --cc=nathan@kernel.org \
    /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.