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 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.