From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Doug Smythies <dsmythies@telus.net>, <mingo@kernel.org>,
<juri.lelli@redhat.com>, <vincent.guittot@linaro.org>,
<dietmar.eggemann@arm.com>, <rostedt@goodmis.org>,
<bsegall@google.com>, <mgorman@suse.de>, <vschneid@redhat.com>,
<linux-kernel@vger.kernel.org>, <wangtao554@huawei.com>,
<quzicheng@huawei.com>, <wuyun.abel@bytedance.com>
Subject: Re: [PATCH 0/4] sched: Various reweight_entity() fixes
Date: Wed, 11 Feb 2026 14:20:31 +0530 [thread overview]
Message-ID: <d3e16de8-cf41-40b0-a976-fb2f37608b70@amd.com> (raw)
In-Reply-To: <4035fa61-cc90-498b-af84-c9ac4903cd5f@amd.com>
[-- Attachment #1: Type: text/plain, Size: 6412 bytes --]
Hello Peter,
On 2/11/2026 11:58 AM, K Prateek Nayak wrote:
> I'll go back and fix my debug patch to give a full view of series of
> events that leads to this but in the meantime I've added the full log
> below if someone wants to take a look.
Attached is archive of trace. Should expand to give a "timeline.trace"
file. Following are some series of events before the failed pick:
Note: "cfs_rq: depth(1) ..." is the cfs_rq which fails but the first
"dump_h_overflow_cfs_rq: cfs_rq: ..." will note depth as "0" which is
the depth of padding and is not the actual cfs-rq depth.
The lines after "pick_task_fair: cfs_rq of overflow:" dumps the cfs_rq
and the queued entities that failed the pick.
...
[006] ... : __enqueue_entity: Enqueue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(-7389160032126894080) sum_weight(2169503744) zero_vruntime(18446744052406571137) sum_shift(0) avg_vruntime(18446744052406571137)
[006] ... : __dequeue_entity: Dequeue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(3512818056739946496) sum_weight(2168455168) zero_vruntime(18446744055883646744) sum_shift(0) avg_vruntime(18446744055883646744)
[006] ... : __enqueue_entity: Enqueue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(1653261820069150720) sum_weight(2169503744) zero_vruntime(18446744056741357296) sum_shift(0) avg_vruntime(18446744056741357296)
[006] ... : __dequeue_entity: Dequeue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(3337798565006147584) sum_weight(2168455168) zero_vruntime(18446744055964215508) sum_shift(0) avg_vruntime(18446744055964215508)
...
[006] ... : __enqueue_entity: Enqueue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(-4817868778594369536) sum_weight(2169503744) zero_vruntime(18446744051221380982) sum_shift(0) avg_vruntime(18446744051221380982)
[006] ... : __dequeue_entity: Dequeue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(8703580922935508992) sum_weight(2168455168) zero_vruntime(18446744053489887930) sum_shift(0) avg_vruntime(18446744053489887930)
...
[006] ... : __enqueue_entity: Enqueue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(1049195167414747136) sum_weight(2169503744) zero_vruntime(18446744057019812035) sum_shift(0) avg_vruntime(18446744057019812035)
[006] ... : __dequeue_entity: Dequeue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(2118331978874880000) sum_weight(2168455168) zero_vruntime(18446744056526599437) sum_shift(0) avg_vruntime(18446744056526599437)
...
[006] ... : __enqueue_entity: Enqueue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(8649466989629145088) sum_weight(2169503744) zero_vruntime(18446744053516583405) sum_shift(0) avg_vruntime(18446744053516583405)
[006] ... : __dequeue_entity: Dequeue cfs_rq: depth(1) weight(2169503744) nr_queued(2069) sum_w_vruntime(-984823152929406976) sum_weight(2168455168) zero_vruntime(18446744049450913118) sum_shift(0) avg_vruntime(18446744049450913118)
...
[006] ... : pick_task_fair: cfs_rq of overflow: /* Essentially failed pick. */
[006] ... : dump_h_overflow_cfs_rq: cfs_rq: ... weight(2169503744) nr_queued(2069) sum_w_vruntime(-59587237455593472) sum_weight(2168455168) zero_vruntime(18446744049024233365) sum_shift(0) avg_vruntime(18446744049024233365)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744057295755695) slice(2800000) deadline(18446744057298552230) curr?(1) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744057379145967) slice(2800000) deadline(18446744057381940989) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744057463106601) slice(2800000) deadline(18446744057465901974) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744057487667304) slice(2800000) deadline(18446744057490461976) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744058420769904) slice(2800000) deadline(18446744058423566108) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744058486927372) slice(2800000) deadline(18446744058489723636) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744061273836896) slice(2800000) deadline(18446744061276631077) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744061535759861) slice(2800000) deadline(18446744061538554473) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744061788668421) slice(2800000) deadline(18446744061791464976) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744062846656914) slice(2800000) deadline(18446744062849454680) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744064164417134) slice(2800000) deadline(18446744064167214230) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(18446744065239426914) slice(2800000) deadline(18446744065242224540) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(880604900) slice(2800000) deadline(883328346) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(880537321) slice(2800000) deadline(883331492) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(880537194) slice(2800000) deadline(883333328) curr?(0) task?(1) delayed?(0) se_depth(1)
[006] ... : dump_h_overflow_entity: se: weight(1048576) vruntime(880540318) slice(2800000) deadline(883334689) curr?(0) task?(1) delayed?(0) se_depth(1)
...
The avg_vruntime(18446744049024233365) = -24685318251 (s64) is smaller
than that of all the vruntime of queued entities.
Peter, Could it be the "left bias" in avg_vruntime() coming into play
with larger "cfs_rq->sum_weight"?
--
Thanks and Regards,
Prateek
[-- Attachment #2: timeline.tar.gz --]
[-- Type: application/x-gzip, Size: 1200020 bytes --]
next prev parent reply other threads:[~2026-02-11 8:50 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 9:34 Peter Zijlstra
2026-01-30 9:34 ` [PATCH 1/4] sched/fair: Only set slice protection at pick time Peter Zijlstra
2026-01-30 15:52 ` Vincent Guittot
2026-01-30 9:34 ` [PATCH 2/4] sched/eevdf: Update se->vprot in reweight_entity() Peter Zijlstra
2026-01-30 16:20 ` Vincent Guittot
2026-01-30 9:34 ` [PATCH 3/4] sched/fair: Increase weight bits for avg_vruntime Peter Zijlstra
2026-01-30 9:34 ` [PATCH 4/4] sched/fair: Revert 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") Peter Zijlstra
2026-01-31 1:47 ` Zhang Qiao
2026-01-31 15:21 ` Peter Zijlstra
2026-02-02 9:12 ` Peter Zijlstra
2026-02-02 9:24 ` Peter Zijlstra
2026-02-02 11:23 ` Zhang Qiao
2026-02-01 17:13 ` [PATCH 0/4] sched: Various reweight_entity() fixes Doug Smythies
2026-02-03 6:45 ` K Prateek Nayak
2026-02-03 11:11 ` Peter Zijlstra
2026-02-03 12:19 ` K Prateek Nayak
2026-02-03 16:36 ` Doug Smythies
2026-02-10 18:13 ` Peter Zijlstra
2026-02-11 5:51 ` Doug Smythies
2026-02-04 10:15 ` K Prateek Nayak
2026-02-09 15:47 ` Peter Zijlstra
2026-02-09 16:52 ` K Prateek Nayak
2026-02-10 5:16 ` K Prateek Nayak
2026-02-10 10:29 ` Peter Zijlstra
2026-02-10 15:41 ` Doug Smythies
2026-02-10 18:09 ` K Prateek Nayak
2026-02-10 18:35 ` Peter Zijlstra
2026-02-10 20:04 ` K Prateek Nayak
2026-02-11 6:28 ` K Prateek Nayak
2026-02-11 8:50 ` K Prateek Nayak [this message]
2026-02-11 23:09 ` Doug Smythies
2026-02-10 18:52 ` Peter Zijlstra
2026-02-10 20:52 ` Vincent Guittot
2026-02-11 5:21 ` Doug Smythies
2026-02-11 8:49 ` Vincent Guittot
2026-02-11 9:01 ` Peter Zijlstra
2026-02-11 10:48 ` Peter Zijlstra
2026-02-11 10:49 ` Peter Zijlstra
2026-02-11 11:15 ` Vincent Guittot
2026-02-11 16:28 ` Peter Zijlstra
2026-02-12 7:43 ` K Prateek Nayak
2026-02-12 11:59 ` Peter Zijlstra
2026-02-12 17:16 ` Peter Zijlstra
2026-02-12 17:24 ` Vincent Guittot
2026-02-12 19:31 ` Peter Zijlstra
2026-02-13 5:22 ` K Prateek Nayak
2026-02-13 6:44 ` Peter Zijlstra
2026-02-13 10:50 ` Peter Zijlstra
2026-02-13 14:29 ` K Prateek Nayak
2026-02-14 6:31 ` Doug Smythies
2026-02-21 22:51 ` Doug Smythies
2026-02-12 19:29 ` Peter Zijlstra
2026-02-12 19:37 ` Doug Smythies
2026-02-13 6:04 ` K Prateek Nayak
2026-02-11 16:21 ` Peter Zijlstra
2026-02-12 5:54 ` Doug Smythies
2026-02-12 7:51 ` Peter Zijlstra
2026-02-12 15:47 ` Doug Smythies
2026-02-12 7:46 ` Peter Zijlstra
2026-02-11 23:25 ` Doug Smythies
2026-02-11 8:48 ` Peter Zijlstra
2026-02-04 10:44 ` Peter Zijlstra
2026-02-14 7:20 ` Shubhang Kaushik
2026-02-16 3:14 ` K Prateek Nayak
2026-02-16 10:59 ` Dietmar Eggemann
2026-02-17 14:37 ` Dietmar Eggemann
2026-02-17 22:02 ` Shubhang Kaushik
2026-02-17 4:20 ` K Prateek Nayak
2026-02-18 18:37 ` Shubhang Kaushik
2026-02-19 7:53 ` Peter Zijlstra
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=d3e16de8-cf41-40b0-a976-fb2f37608b70@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=dsmythies@telus.net \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=quzicheng@huawei.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=wangtao554@huawei.com \
--cc=wuyun.abel@bytedance.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
Powered by JetHome