From: "Aaron Lu" <ziqianlu@bytedance.com>
To: "Zicheng Qu" <quzicheng@huawei.com>
Cc: "K Prateek Nayak" <kprateek.nayak@amd.com>,
<peterz@infradead.org>, <bsegall@google.com>,
<dhaval@linux.vnet.ibm.com>, <dietmar.eggemann@arm.com>,
<juri.lelli@redhat.com>, <linux-kernel@vger.kernel.org>,
<mgorman@suse.de>, <mingo@redhat.com>, <rostedt@goodmis.org>,
<tanghui20@huawei.com>, <vatsa@linux.vnet.ibm.com>,
<vincent.guittot@linaro.org>, <vschneid@redhat.com>,
<zhangqiao22@huawei.com>
Subject: Re: [PATCH] sched: Re-evaluate scheduling when migrating queued tasks out of throttled cgroups
Date: Mon, 2 Feb 2026 15:09:15 +0800 [thread overview]
Message-ID: <20260202070915.GA3246252@bytedance.com> (raw)
In-Reply-To: <1594f461-549c-4db9-b80e-63c48818fc5b@huawei.com>
On Fri, Jan 30, 2026 at 05:03:49PM +0800, Zicheng Qu wrote:
> On 1/30/2026 4:34 PM, Zicheng Qu wrote:
>
> > 4) For kernel <= 5.10: Later, cgroup A is unthrottled. However, the task
> > P has already been migrated out of cgroup A, so unthrottle_cfs_rq()
> > may observe load_weight == 0 and return early without resched_curr()
> > called. For kernel >= 6.6: The unthrottling path normally triggers
> > `resched_curr()` almost cases even when no runnable tasks remain in the
> > unthrottled cgroup, preventing the idle stall described above. However,
> > if cgroup A is removed before it gets unthrottled, the unthrottling path
> > for cgroup A is never executed. In a result, no `resched_curr()` can be
> > called.
I think you are right.
> Hi Aaron,
>
> Apologies for the confusion in my earlier description — the original
> failure model was identified and analyzed on kernels based on LTS 5.10.
>
> Later I realized that on v6.6 and mainline, the issue becomes much harder
> to reproduce due to additional conditions introduced in the condition
> (cfs_rq->on_list) in unthrottle_cfs_rq(), which effectively mask the
> original reproduction path.
>
> As a result, I adjusted the reproducer accordingly. With the updated
> reproducer, the issue can still be triggered on mainline by explicitly
> bypassing the unthrottling reschedule path, as described in the commit
> message.
>
I can reproduce the problem using your reproducer now and also verified
your patch fixed the problem, so feel free to add:
Tested-by: Aaron Lu <ziqianlu@bytedance.com>
next prev parent reply other threads:[~2026-02-02 7:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 13:30 [PATCH] sched: Re-evaluate scheduling when migrating queued tasks out of throttled cgroups Zicheng Qu
2026-01-20 3:33 ` K Prateek Nayak
2026-01-20 3:25 ` Zicheng Qu
2026-01-21 3:49 ` Aaron Lu
2026-01-21 5:24 ` K Prateek Nayak
2026-01-21 6:34 ` Aaron Lu
2026-01-30 8:34 ` Zicheng Qu
2026-01-30 9:03 ` Zicheng Qu
2026-02-02 7:09 ` Aaron Lu [this message]
2026-02-02 12:49 ` Peter Zijlstra
2026-02-03 11:18 ` [tip: sched/core] " tip-bot2 for Zicheng Qu
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=20260202070915.GA3246252@bytedance.com \
--to=ziqianlu@bytedance.com \
--cc=bsegall@google.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=quzicheng@huawei.com \
--cc=rostedt@goodmis.org \
--cc=tanghui20@huawei.com \
--cc=vatsa@linux.vnet.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=zhangqiao22@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox