Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <457e1f88-4eb0-53c4-a750-c8930c803272@arm.com>
Date:   Thu, 14 Apr 2022 11:38:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [Linux 5.18-rc1] WARNING: CPU: 1 PID: 0 at
 kernel/sched/fair.c:3355 update_blocked_averages
Content-Language: en-US
To:     Ammar Faizi <ammarfaizi2@gnuweeb.org>,
        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>
 <675544de-3369-e26e-65ba-3b28fff5c126@gnuweeb.org>
 <000457c2-57af-95e3-7dff-2cbd99f0de5f@arm.com>
 <7f4b3fbf-c7c6-22cb-019b-520ad6a663aa@gnuweeb.org>
 <786190b3-b2cb-464d-9808-325d774c62a5@arm.com>
 <e1f9421d-e9dd-589c-bf88-407533e40797@gnuweeb.org>
From:   Dietmar Eggemann <dietmar.eggemann@arm.com>
In-Reply-To: <e1f9421d-e9dd-589c-bf88-407533e40797@gnuweeb.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 08/04/2022 08:03, Ammar Faizi wrote:
> On 4/7/22 5:52 PM, Dietmar Eggemann wrote:
> 
> [...]
> 
>> Looks like 21.10 finally abandoned legacy cgroup v1 and switched to v2
>> completely, which is now mounted under /sys/fs/cgroup .
>>
>> So your /sys/fs/cgroup/cgroup.controllers should contain `cpu`.
>>
>> Can you check if any of the cpu.max files under /sys/fs/cgroup has
>> something else then `max 100000` ?
> 
> I only see "max 100000" at the moment. Not sure if it may change when I
> do other activities anyway. If you need more information, I can always
> send it, so feel free to ask.

Looks like you saw the same issue which got fixed here:

https://lkml.kernel.org/r/20220414015940.9537-1-kuyo.chang@mediatek.com

So nothing to do with CFS BW control. It's triggered by a task with very
low nice value and load_avg=1 during cfs_rq attach.