Re: [PATCH 0/4] sched: Various reweight_entity() fixes
From: K Prateek Nayak
Date: Thu Feb 12 2026 - 02:49:48 EST
Hello Peter,
On 2/11/2026 9:58 PM, Peter Zijlstra wrote:
> On Wed, Feb 11, 2026 at 12:15:48PM +0100, Vincent Guittot wrote:
>
>> Regarding the use of calc_delta_fair() in update_entity_lag(), we use
>> calc_delta_fair() for updating vruntime, deadline, vprot and vlag and
>> I wonder how this diff of granularity compared to avg_vruntime can be
>> an issue for sched_entity with a small weight
>
> It will effectively inflate their weight.
>
> The below seems to 'work' -- it builds, boots and builds a kernel.
>
> We could perhaps look at doing that reciprocal thing on unsigned long,
> but meh.
So I was testing peterz:sched/core at commit 84230c0ac1cf ("sched/fair:
Use full weight to __calc_delta()") and it still crashes for the
exorbitantly large copies of "yes" running on 6 cores.
Here is what I've found out from today's crash on dumping the offending
cfs_rq:
...
Enqueue cfs_rq: depth(1) weight(2144337920) nr_queued(2045) sum_w_vruntime(18343811230990336) sum_weight(2144337920) zero_vruntime(18337852274) sum_shift(0) avg_vruntime(18337852274)
Dequeue cfs_rq: depth(1) weight(2144337920) nr_queued(2045) sum_w_vruntime(1303379968) sum_weight(2143289344) zero_vruntime(18354971669) sum_shift(0) avg_vruntime(18354971669)
Enqueue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-31233567079006208) sum_weight(2152726528) zero_vruntime(18360916028) sum_shift(0) avg_vruntime(18360916028)
Dequeue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-25773095996358656) sum_weight(2151677952) zero_vruntime(18366916795) sum_shift(0) avg_vruntime(18366916795)
Enqueue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-195993505307295744) sum_weight(2152726528) zero_vruntime(18437453448) sum_shift(0) avg_vruntime(18437453448)
Dequeue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-355777007188967424) sum_weight(2151677952) zero_vruntime(18520289238) sum_shift(0) avg_vruntime(18520289238)
Enqueue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-1523774576650092544) sum_weight(2152726528) zero_vruntime(19054245803) sum_shift(0) avg_vruntime(19054245803)
Dequeue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-3015239905359953920) sum_weight(2151677952) zero_vruntime(19756286051) sum_shift(0) avg_vruntime(19756286051)
# I'm suspecting something goes sideways at this point looking at
# the big jump that comes after in avg_vruntime()
# "6222537296247259136" has bit 63 set so could it be a wraparound
# in sum_w_vruntime?
Enqueue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(6222537296247259136) sum_weight(2152726528) zero_vruntime(24024889432) sum_shift(0) avg_vruntime(24024889432)
Dequeue cfs_rq: depth(1) weight(2152726528) nr_queued(2053) sum_w_vruntime(-5928597400870453248) sum_weight(2151677952) zero_vruntime(21110281285) sum_shift(0) avg_vruntime(21110281285)
cfs_rq of failed pick:
cfs_rq: depth(0) weight(2176843776) nr_queued(2076) sum_w_vruntime(-90907067772043264) sum_weight(2175795200) zero_vruntime(26921355273)
se: weight(1048576) vruntime(843832351) slice(2800000) deadline(846630448) curr?(1) task?(1) delayed?(0) se_depth(1)
se: weight(1048576) vruntime(839841550) slice(2800000) deadline(842635020) curr?(0) task?(1) delayed?(0) se_depth(1)
...
# Many entities have weight 1048576, and and vruntime around ~850,000
....
se: weight(1048576) vruntime(843832916) slice(2800000) deadline(846629681) curr?(0) task?(1) delayed?(0) se_depth(1)
se: weight(1048576) vruntime(843833563) slice(2800000) deadline(846630939) curr?(0) task?(1) delayed?(0) se_depth(1)
se: weight(1048576) vruntime(843840684) slice(2800000) deadline(846633192) curr?(0) task?(1) delayed?(0) se_depth(1)
se: weight(1048576) vruntime(18344670326) slice(2800000) deadline(18347465508) curr?(0) task?(1) delayed?(0) se_depth(1)
se: weight(1048576) vruntime(18344679852) slice(2800000) deadline(18347475866) curr?(0) task?(1) delayed?(0) se_depth(1)
se: weight(1048576) vruntime(18344682061) slice(2800000) deadline(18347477764) curr?(0) task?(1) delayed?(0) se_depth(1)
...
# Many entities have weight 1048576, and and vruntime around ~18,344,682,061
I'm running with CONFIG_HZ=250. In vruntime_eligible() we have for curr:
entity_key(curr) = -26077522922LL
weight = 1048576UL
For the cfs_rq we get:
avg = sum_w_runtime + (entity_key * weight) = -118251332447502336LL
load = sum_weight + weight = 2176843776UL
But on the way to check eligibility we compute:
entity_key * load = -56766693466253033472 (in python)
entity_key * load = -1426461245124378624LL (in C)
vruntime_eligible() returns false always as a result of the overflow and
we land in a pickle. Not sure if sum_w_vruntime itself can suffer from
a wrap around that leads to all this.
Parsing the stats based on the dump in Python gives me:
Total weight: 2176843776 (checks out)
Total weighted vruntime: 3145101113938673664
Avg (floating point): 1444798725.849711
Avg (signed 64-bit): 1444798725
Avg (unsigned 64-bit): 1444798725
which is a bit far off from the dumped stats of cfs_rq.
--
Thanks and Regards,
Prateek