From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: John Stultz <jstultz@google.com>, Xuewen Yan <xuewen.yan94@gmail.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Juri Lelli" <juri.lelli@redhat.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Benjamin Segall" <bsegall@google.com>,
"Mel Gorman" <mgorman@suse.de>,
"Valentin Schneider" <vschneid@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
"王科 (Ke Wang)" <Ke.Wang@unisoc.com>,
"Xuewen Yan" <xuewen.yan@unisoc.com>,
"hongyu.jin@unisoc.com" <hongyu.jin@unisoc.com>,
guohua.yan@unisoc.com
Subject: Re: [Question] Sched: Severe scheduling latency (>10s) observed on kernel 6.12 with specific workload
Date: Tue, 14 Apr 2026 16:43:06 +0100 [thread overview]
Message-ID: <9ca931c1-8d4a-4c98-a962-2e36072db04e@arm.com> (raw)
In-Reply-To: <CANDhNCrFHras=ngU2rfR6vBgRScg7N=3mMv=sxfB8=yvEV_biA@mail.gmail.com>
On 13.04.26 21:44, John Stultz wrote:
> On Thu, Apr 9, 2026 at 9:01 PM John Stultz <jstultz@google.com> wrote:
>>
>> On Thu, Apr 9, 2026 at 8:31 PM Xuewen Yan <xuewen.yan94@gmail.com> wrote:
[...]
>
> So unfortuantely, it looks like I'm going to have to eat my words here. :(
>
> In the android16-6.12 tree, the behavior has been isolated down to a
> backport of commit 6d71a9c61604 ("sched/fair: Fix EEVDF entity
> placement bug causing scheduling lag").
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d71a9c6160479899ee744d2c6d6602a191deb1f
>
> Specifically the `place_entity(cfs_rq, se, 0);` addition in `reweight_entity()`
>
> I was assuming android16-6.12 was missing other related changes
> causing the bad behavior, but Xuewen pointed out similar problems
> could be seen on android17-6.18. I aligned that tree to the
> 6.18-stable branch, and could also reproduce it. Additionally, I
> tested with our andorid-mainline branch (as of 6.19 the base) and it
> showed the same issue. So this does "look" to be upstream related.
>
> Removing the place_entity() line added in commit 6d71a9c61604 from
> reweight_entity() seems to prevent the behavior.
>
> I've been able to trigger this "bad behavior" on devices using the
> rt-app with the configuration[1] Xuewen first provided (putting 10
> spinners per cpu on the bottom 4 cpus in a background v1 cpu cgroup).
> Then I run `cyclictest -m -t -a --policy=SCHED_OTHER -b 1000000 -D
> 120s` in the root cgroup, and (usually well) within two minutes I'll
> see > 1second delays in cyclictest.
>
> If I remove the cgroup from the rt-app config, the issue doesn't reproduce.
>
> Unfortuantely I've only been able to reproduce this on device, which
> requires the android kernel tree. I've installed an old debian11 image
> on x86 QEMU to be able to utilize cpu v1 cgroup support, but I haven't
> reproduced the issue there, which is a bit confounding.
>
> The issue doesn't immediatley trigger, but usually after a few seconds
> of normal behavior I'll start to see cyclictest on one or two of the
> cpus start to trip larger 100ms+ latencies until it hits the 1second
> boundary.
>
> Late last week I went digging into place_entity() to try to understand
> why it was tripping, but wasn't very succesful in narrowing down what
> might be going wrong. I did see that the place_entity() call seems to
> always be on a non-task se, and its almost always exiting at the `if
> (se->rel_deadline)` case. It does go through the lag calculation
> conditional, but not always.
>
> Anyway, I'm going to continue digging into this, but I just wanted to
> give folks a heads up in case there were any ideas to explore.
>
> thanks
> -john
>
>
> [1] Xuewen's rt-app config:
> {
> "tasks" : {
> "t0" : {
> "instance" : 40,
> "priority" : 0,
> "cpus" : [ 0, 1, 2, 3 ],
> "taskgroup" : "/background",
> "loop" : -1,
> "run" : 200,
> "sleep" : 50
> }
> }
> }
Just guessing ... does Android do more task
reweights (set_load_weight(p, true)) ?
on tip sched/core:
[PATCH v2 0/7] sched: Various reweight_entity() fixes
https://lore.kernel.org/r/20260219075840.162631716@infradead.org
db4551e2ba34 - sched/fair: Use full weight to __calc_delta() (2026-02-23
Peter Zijlstra)
101f3498b4bd - sched/fair: Revert 6d71a9c61604 ("sched/fair: Fix EEVDF
entity placement bug causing scheduling lag") (2026-02-23 Peter
Zijlstra) <-- !!!
4823725d9d1d - sched/fair: Increase weight bits for avg_vruntime
(2026-02-23 Peter Zijlstra)
9fe89f022c05 - sched/fair: More complex proportional newidle balance
(2026-02-23 Peter Zijlstra)
v7.0
6e3c0a4e1ad1 - sched/fair: Fix lag clamp (2026-02-23 Peter Zijlstra)
bcd74b2ffdd0 - sched/fair: Only set slice protection at pick time
(2026-02-23 Peter Zijlstra)
b3d99f43c72b - sched/fair: Fix zero_vruntime tracking (2026-02-23 Peter
Zijlstra)
next prev parent reply other threads:[~2026-04-14 15:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAB8ipk9N5_pO1Awp6PLnWt6hf1Bu_XtY3qGMJKqz=Uf6eZQejw@mail.gmail.com>
2026-04-01 4:25 ` John Stultz
2026-04-01 6:04 ` Xuewen Yan
2026-04-01 10:05 ` Vincent Guittot
2026-04-01 10:48 ` Xuewen Yan
2026-04-01 13:00 ` Dietmar Eggemann
2026-04-02 5:16 ` Xuewen Yan
2026-04-02 14:58 ` Dietmar Eggemann
2026-04-08 2:50 ` Xuewen Yan
2026-04-10 11:13 ` Dietmar Eggemann
2026-04-14 5:18 ` Xuewen Yan
2026-04-14 15:49 ` Dietmar Eggemann
2026-04-01 14:01 ` Vincent Guittot
2026-04-02 5:11 ` Xuewen Yan
2026-04-02 5:24 ` Xuewen Yan
2026-04-08 12:19 ` David Laight
2026-04-09 21:39 ` John Stultz
2026-04-10 3:31 ` Xuewen Yan
2026-04-10 4:01 ` John Stultz
2026-04-10 12:24 ` Dietmar Eggemann
2026-04-13 20:44 ` John Stultz
2026-04-14 15:43 ` Dietmar Eggemann [this message]
2026-04-14 19:21 ` John Stultz
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=9ca931c1-8d4a-4c98-a962-2e36072db04e@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=Ke.Wang@unisoc.com \
--cc=bsegall@google.com \
--cc=guohua.yan@unisoc.com \
--cc=hongyu.jin@unisoc.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xuewen.yan94@gmail.com \
--cc=xuewen.yan@unisoc.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
all inboxes | Powered by JetHome®