Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <675544de-3369-e26e-65ba-3b28fff5c126@gnuweeb.org>
Date:   Tue, 5 Apr 2022 20:13:42 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-US
To:     Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc:     Ben Segall <bsegall@google.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        GNU/Weeb Mailing List <gwml@vger.gnuweeb.org>,
        Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Mel Gorman <mgorman@suse.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Vincent Guittot <vincent.guittot@linaro.org>
References: <b86541ea-7d96-5a24-1b65-37c24c70d3ff@gnuweeb.org>
 <f71d132d-02a0-918c-ab2b-3234d0d492a4@arm.com>
From:   Ammar Faizi <ammarfaizi2@gnuweeb.org>
Subject: Re: [Linux 5.18-rc1] WARNING: CPU: 1 PID: 0 at
 kernel/sched/fair.c:3355 update_blocked_averages
In-Reply-To: <f71d132d-02a0-918c-ab2b-3234d0d492a4@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 4/5/22 7:21 PM, Dietmar Eggemann wrote:
> Tried to recreate the issue but no success so far. I used you config
> file, clang-14 and a Xeon CPU E5-2690 v2 (2 sockets 40 CPUs) with 20
> two-level cgoupv1 taskgroups '/X/Y' with 'hackbench (10 groups, 40 fds)
> + idling' running in all '/X/Y/'.
> 
> What userspace are you running?

HP Laptop, Intel i7-1165G7, 8 CPUs, with 16 GB of RAM. Ubuntu 21.10. Just for
daily workstation. Compiling kernel, browsing and coding stuff.

> There seemed to be some pressure on your machine when it happened?

Yeah, might be, I don't fully remember the activity at the time it
happened, though.

>> <6>[13420.623334][    C7] perf: interrupt took too long (2530 > 2500),
>> lowering kernel.perf_event_max_sample_rate to 78900
> 
> Maybe you could split the SCHED_WARN_ON so we know which signal causes this?

OK, I will apply the diff on top of 5.18-rc1 and will start using it for daily
routine tomorrow morning. Let's see if I can hit this bug again. Will send an
update later...

Thank you.

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index d4bd299d67ab..0d45e09e5bfc 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3350,9 +3350,9 @@ static inline bool cfs_rq_is_decayed(struct cfs_rq
> *cfs_rq)
>           * Make sure that rounding and/or propagation of PELT values never
>           * break this.
>           */
> -       SCHED_WARN_ON(cfs_rq->avg.load_avg ||
> -                     cfs_rq->avg.util_avg ||
> -                     cfs_rq->avg.runnable_avg);
> +       SCHED_WARN_ON(cfs_rq->avg.load_avg);
> +       SCHED_WARN_ON(cfs_rq->avg.util_avg);
> +       SCHED_WARN_ON(cfs_rq->avg.runnable_avg);
> 
>          return true;
>   }
> 
> [...]


-- 
Ammar Faizi