From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=NICE_REPLY_A,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gnuweeb.org (Postfix) with ESMTP id 2A4717E3A0 for ; Thu, 14 Apr 2022 09:38:41 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 170C6139F; Thu, 14 Apr 2022 02:38:40 -0700 (PDT) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CA0993F5A1; Thu, 14 Apr 2022 02:38:37 -0700 (PDT) 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 , Linux Kernel Mailing List Cc: Ben Segall , Daniel Bristot de Oliveira , GNU/Weeb Mailing List , Ingo Molnar , Juri Lelli , Mel Gorman , Peter Zijlstra , Steven Rostedt , Vincent Guittot References: <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> From: Dietmar Eggemann In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: 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.