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
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 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 \
    --subject='Re: WARNING: CPU: 112 PID: 2041 at kernel/sched/sched.h:1453' \
    /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

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.