kernel/sched/fair.c | 9 +++++++++ 1 file changed, 9 insertions(+)
Hi all,
While analyzing cgroup weight adjustment scenarios in EEVDF, I observed a
potential vruntime underflow issue caused by unconstrained vlag scaling in
rescale_entity(). I would like to consult the community on whether this
behavior is expected or if it represents a bug in the current implementation.
I notice this my trace in a multi-level cgroup environment:
CPU 3
CURRENT: PID: 12485 TASK: ffff003027f49440 COMMAND: "cpu_sim"
ROOT_TASK_GROUP: ffffd714095439c0 CFS_RQ: ffff002fbfa3d140
TASK_GROUP: ffff00211fdfe800 CFS_RQ: ffff00213f2c9800 <throttle_test>
TASK_GROUP: ffff20300f2e7000 CFS_RQ: ffff0021190ca000 <case_cpu_idle>
TASK_GROUP: ffff203016880c00 CFS_RQ: ffff00211ece4c00 <child_1>
[120] PID: 12485 TASK: ffff003027f49440 COMMAND: "cpu_sim" [CURRENT]
TASK_GROUP: ffff203016884000 CFS_RQ: ffff002156835c00 <child_2>
[120] PID: 12649 TASK: ffff003027f4e540 COMMAND: "cpu_sim"
Trace Metrics (Before/After rescale_entity and update_load_set):
Before: weight: 209715, avruntime: 7738112562, vlag: 3638691801, vruntime: 4099420761
After: weight: 614, avruntime: 7738112562, vlag: 1242814741118, vruntime: 4099420761, limit: 724001488558
(vruntime/avruntime stay unchanged; the scaling only touches vlag, deadline, and vprot)
Weight drop (209715->614) during __sched_group_set_shares() causes se->vlag
to explode in rescale_entity(), surged from 3638691801 to 1242814741118.
When the entity's vruntime is subsequently updated via se->vruntime =
avruntime - se->vlag, the massive vlag value leads to a underflow of
se->vruntime.
Furthermore, I noticed that while entity_lag() typically applies a limit (calculated
as 724001488558 in this instance) to constrain se->vlag, rescale_entity() performs
the scaling without any such boundary checks. This allows se->vlag to exceed the
theoretical limits expected by the EEVDF algorithm.
Questions:
1. Is this se->vruntime underflow during drastic weight reduction considered acceptable
within the current EEVDF design?
2. Should rescale_entity() apply a limit check (similar to entity_lag()) immediately
after scaling the vlag to prevent it from escaping reasonable bounds?
Something like this?
Signed-off-by: Chen Jinghuang <chenjinghuang2@huawei.com>
---
kernel/sched/fair.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3ebec186f982..351e2f7b4b28 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4046,6 +4046,15 @@ rescale_entity(struct sched_entity *se, unsigned long weight, bool rel_vprot)
*/
se->vlag = div64_long(se->vlag * old_weight, weight);
+ {
+ u64 max_slice = cfs_rq_max_slice(cfs_rq_of(se)) + TICK_NSEC;
+ s64 limit;
+
+ limit = calc_delta_fair(max_slice, se);
+
+ se->vlag = clamp(se->vlag, -limit, limit);
+ }
+
/*
* DEADLINE
* --------
--
2.34.1Hello Chen,
On 5/14/2026 6:55 PM, Chen Jinghuang wrote:
> Hi all,
>
> While analyzing cgroup weight adjustment scenarios in EEVDF, I observed a
> potential vruntime underflow issue caused by unconstrained vlag scaling in
> rescale_entity(). I would like to consult the community on whether this
> behavior is expected or if it represents a bug in the current implementation.
>
> I notice this my trace in a multi-level cgroup environment:
>
> CPU 3
> CURRENT: PID: 12485 TASK: ffff003027f49440 COMMAND: "cpu_sim"
> ROOT_TASK_GROUP: ffffd714095439c0 CFS_RQ: ffff002fbfa3d140
> TASK_GROUP: ffff00211fdfe800 CFS_RQ: ffff00213f2c9800 <throttle_test>
> TASK_GROUP: ffff20300f2e7000 CFS_RQ: ffff0021190ca000 <case_cpu_idle>
> TASK_GROUP: ffff203016880c00 CFS_RQ: ffff00211ece4c00 <child_1>
> [120] PID: 12485 TASK: ffff003027f49440 COMMAND: "cpu_sim" [CURRENT]
> TASK_GROUP: ffff203016884000 CFS_RQ: ffff002156835c00 <child_2>
> [120] PID: 12649 TASK: ffff003027f4e540 COMMAND: "cpu_sim"
>
> Trace Metrics (Before/After rescale_entity and update_load_set):
>
> Before: weight: 209715, avruntime: 7738112562, vlag: 3638691801, vruntime: 4099420761
> After: weight: 614, avruntime: 7738112562, vlag: 1242814741118, vruntime: 4099420761, limit: 724001488558
> (vruntime/avruntime stay unchanged; the scaling only touches vlag, deadline, and vprot)
>
> Weight drop (209715->614) during __sched_group_set_shares() causes se->vlag
> to explode in rescale_entity(), surged from 3638691801 to 1242814741118.
>
> When the entity's vruntime is subsequently updated via se->vruntime =
> avruntime - se->vlag, the massive vlag value leads to a underflow of
> se->vruntime.
>
> Furthermore, I noticed that while entity_lag() typically applies a limit (calculated
> as 724001488558 in this instance) to constrain se->vlag, rescale_entity() performs
> the scaling without any such boundary checks. This allows se->vlag to exceed the
> theoretical limits expected by the EEVDF algorithm.
The vlag, to begin with, would be within theoretical limits right?
Rescaling it should also put it under theoretical limits if I'm not
wrong.
>
> Questions:
> 1. Is this se->vruntime underflow during drastic weight reduction considered acceptable
> within the current EEVDF design?
All the vruntime considerations use signed delta from the zero_vruntime
so based on my understanding, it should be fine.
> 2. Should rescale_entity() apply a limit check (similar to entity_lag()) immediately
> after scaling the vlag to prevent it from escaping reasonable bounds?
>
> Something like this?
>
> Signed-off-by: Chen Jinghuang <chenjinghuang2@huawei.com>
> ---
> kernel/sched/fair.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 3ebec186f982..351e2f7b4b28 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4046,6 +4046,15 @@ rescale_entity(struct sched_entity *se, unsigned long weight, bool rel_vprot)
> */
> se->vlag = div64_long(se->vlag * old_weight, weight);
This vlag is already calculated using entity_lag() which is within the
theoretical limits and is being scaled proportionally.
>
> + {
> + u64 max_slice = cfs_rq_max_slice(cfs_rq_of(se)) + TICK_NSEC;
This should also consider if "se" has the largest slice since it is
outside of the cfs_rq at this point.
> + s64 limit;
> +
> + limit = calc_delta_fair(max_slice, se);
update_load_set() is done after rescale_entity(). The above should
actually scale the limits based on the new weight.
> +
> + se->vlag = clamp(se->vlag, -limit, limit);
If we use the updated weight, se->vlag should already be within
those limits.
> + }
> +
> /*
> * DEADLINE
> * --------
--
Thanks and Regards,
Prateek
- kernel6.18.21 reproduce the same questioin
<4>[ 10.010851][T1080@C3] CPU: 3 UID: 0 PID: 1080 Comm: Jit thread pool Tainted: G W OE 6.18.21-android17-5-4k #1 PREEMPT e342f73d9fa572b2982020b3450c2e97788f7722
<4>[ 10.010862][T1080@C3] Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
<4>[ 10.010872][T1080@C3] pstate: a04000c5 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
<4>[ 10.010877][T1080@C3] pc : pick_task_fair+0xe8/0x194
<4>[ 10.010890][T1080@C3] lr : pick_task_fair+0xe8/0x194
<4>[ 10.010896][T1080@C3] sp : ffffffc0861dbc80
<4>[ 10.010899][T1080@C3] x29: ffffffc0861dbc80 x28: 0000000000000001 x27: ffffffe566a99000
<4>[ 10.010911][T1080@C3] x26: ffffffe566aa4000 x25: ffffffe566aa4380 x24: 0000000000000000
<4>[ 10.010922][T1080@C3] x23: 0000000000000002 x22: ffffff8176720840 x21: 0000000000000000
<4>[ 10.010933][T1080@C3] x20: ffffff8176720840 x19: ffffff8176720640 x18: ffffffc08603d040
<4>[ 10.010944][T1080@C3] x17: 00000000000004e9 x16: fbb79c5646e08229 x15: 0000000000000000
<4>[ 10.010954][T1080@C3] x14: 0000000000000002 x13: 00000000000004e7 x12: 0000000000000000
<4>[ 10.010965][T1080@C3] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffff808ae3ba00
<4>[ 10.010975][T1080@C3] x8 : 0000021ba4e7ceed x7 : 203a746978655f71 x6 : 0000000000000000
<4>[ 10.010986][T1080@C3] x5 : ffffff8086d668a5 x4 : 0000000000000000 x3 : 0000000000000010
<4>[ 10.010996][T1080@C3] x2 : ffffffc0861dbd80 x1 : 00000002f840e58a x0 : 0000000000000000
<4>[ 10.011007][T1080@C3] Call trace:
<4>[ 10.011012][T1080@C3] pick_task_fair+0xe8/0x194 (P)
<4>[ 10.011020][T1080@C3] pick_next_task_fair+0x78/0x794
<4>[ 10.011027][T1080@C3] __schedule+0x2a0/0xf38
<4>[ 10.011036][T1080@C3] schedule+0x11c/0x1c4
<4>[ 10.011042][T1080@C3] exit_to_user_mode_loop+0x78/0x1ac
<4>[ 10.011052][T1080@C3] el0_interrupt+0xac/0x108
<4>[ 10.011059][T1080@C3] __el0_irq_handler_common+0x18/0x28
<4>[ 10.011066][T1080@C3] el0t_64_irq_handler+0x10/0x1c
<4>[ 10.011071][T1080@C3] el0t_64_irq+0x1c4/0x1c8
- pick_eevdf() return NULL
5766 se = pick_eevdf(cfs_rq);
5767 if (se->sched_delayed) {
5768 dequeue_entities(rq, se, DEQUEUE_SLEEP | DEQUEUE_DELAYED);
5769 /*
5770 * Must not reference @se again, see __block_task().
5771 */
5772 return NULL;
- cpu3 cfs_rq hierarchy
CPU3 rq (0xffffff8176720640)
│
└── cfs_rq root (0xffffff8176720840) zero_vruntime = 10,906,890,879 (0x28a19f27f)
│ nr_queued=3, h_nr_queued=2
│ sum_w_vruntime=2,317,754,027,757, sum_weight=1255
│
├── [cfs.curr] top-app cgroup sched_entity (0xffffff808ae3ba00) depth=0,
│ vruntime = 18,292,439,848,198,753,309 (0xfe07b9c2e8d6380d)
│ entity_key = −154,304,236,417,689,186 (0xfddbcd1d50fc599e)
│
├── cp_diskserver_v (se @ 0xffffff80fa4456c0) PID 1230, depth=0
│ vruntime = 12,753,429,279
│ entity_key = +1,846,538,400 (0x6e0ff0a0)
── child top-app cfs_rq (0xffffff808ae3aa00) zero_vruntime = 1,355,080,745 (0x50c4e429)
nr_queued=1
│
└── [cfs.curr] Jit thread pool (se @ 0xffffff80dca300c0) PID 1080, depth=1
parent → 0xffffff808ae3ba00
vruntime = 1,715,893,071
entity_key = +360,812,326 (0x15818f26)
(cpu3 rq->curr is "Jit thread pool")
- cfs_rq of cpu3
crash-arm64_v9.0.0_k618> cfs_rq.h_nr_runnable,sum_w_vruntime,sum_weight,zero_vruntime 0xffffff8176720840
h_nr_runnable = 2,
sum_w_vruntime = 2317754027757,
sum_weight = 1255,
zero_vruntime = 10906890879,
- sched_entity of cpu3 top-app cgroup
crash-arm64_v9.0.0_k618> sched_entity.deadline,vruntime,on_rq,vprot,vlag,slice,load 0xffffff808ae3ba00
deadline = 8715622320990,
vruntime = 18292439848198753309,
on_rq = 1 '\001',
vprot = 154304236428637793
vlag = 154304236428637793,
slice = 2800000,
load = {
weight = 46,
inv_weight = 2147483647
},
vruntime and vlag abnormal, The vruntime exception is caused by the vlag exception.
Hongyu Jin <hongyu.jin.cn@gmail.com> 于2026年6月2日周二 20:16写道：
>
> - kernel6.18.21 reproduce the same questioin
> <4>[ 10.010851][T1080@C3] CPU: 3 UID: 0 PID: 1080 Comm: Jit thread pool Tainted: G W OE 6.18.21-android17-5-4k #1 PREEMPT e342f73d9fa572b2982020b3450c2e97788f7722
> <4>[ 10.010862][T1080@C3] Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> <4>[ 10.010872][T1080@C3] pstate: a04000c5 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> <4>[ 10.010877][T1080@C3] pc : pick_task_fair+0xe8/0x194
> <4>[ 10.010890][T1080@C3] lr : pick_task_fair+0xe8/0x194
> <4>[ 10.010896][T1080@C3] sp : ffffffc0861dbc80
> <4>[ 10.010899][T1080@C3] x29: ffffffc0861dbc80 x28: 0000000000000001 x27: ffffffe566a99000
> <4>[ 10.010911][T1080@C3] x26: ffffffe566aa4000 x25: ffffffe566aa4380 x24: 0000000000000000
> <4>[ 10.010922][T1080@C3] x23: 0000000000000002 x22: ffffff8176720840 x21: 0000000000000000
> <4>[ 10.010933][T1080@C3] x20: ffffff8176720840 x19: ffffff8176720640 x18: ffffffc08603d040
> <4>[ 10.010944][T1080@C3] x17: 00000000000004e9 x16: fbb79c5646e08229 x15: 0000000000000000
> <4>[ 10.010954][T1080@C3] x14: 0000000000000002 x13: 00000000000004e7 x12: 0000000000000000
> <4>[ 10.010965][T1080@C3] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffff808ae3ba00
> <4>[ 10.010975][T1080@C3] x8 : 0000021ba4e7ceed x7 : 203a746978655f71 x6 : 0000000000000000
> <4>[ 10.010986][T1080@C3] x5 : ffffff8086d668a5 x4 : 0000000000000000 x3 : 0000000000000010
> <4>[ 10.010996][T1080@C3] x2 : ffffffc0861dbd80 x1 : 00000002f840e58a x0 : 0000000000000000
> <4>[ 10.011007][T1080@C3] Call trace:
> <4>[ 10.011012][T1080@C3] pick_task_fair+0xe8/0x194 (P)
> <4>[ 10.011020][T1080@C3] pick_next_task_fair+0x78/0x794
> <4>[ 10.011027][T1080@C3] __schedule+0x2a0/0xf38
> <4>[ 10.011036][T1080@C3] schedule+0x11c/0x1c4
> <4>[ 10.011042][T1080@C3] exit_to_user_mode_loop+0x78/0x1ac
> <4>[ 10.011052][T1080@C3] el0_interrupt+0xac/0x108
> <4>[ 10.011059][T1080@C3] __el0_irq_handler_common+0x18/0x28
> <4>[ 10.011066][T1080@C3] el0t_64_irq_handler+0x10/0x1c
> <4>[ 10.011071][T1080@C3] el0t_64_irq+0x1c4/0x1c8
>
> - pick_eevdf() return NULL
> 5766 se = pick_eevdf(cfs_rq);
> 5767 if (se->sched_delayed) {
> 5768 dequeue_entities(rq, se, DEQUEUE_SLEEP | DEQUEUE_DELAYED);
> 5769 /*
> 5770 * Must not reference @se again, see __block_task().
> 5771 */
> 5772 return NULL;
>
> - cpu3 cfs_rq hierarchy
> CPU3 rq (0xffffff8176720640)
> │
> └── cfs_rq root (0xffffff8176720840) zero_vruntime = 10,906,890,879 (0x28a19f27f)
> │ nr_queued=3, h_nr_queued=2
> │ sum_w_vruntime=2,317,754,027,757, sum_weight=1255
> │
> ├── [cfs.curr] top-app cgroup sched_entity (0xffffff808ae3ba00) depth=0,
> │ vruntime = 18,292,439,848,198,753,309 (0xfe07b9c2e8d6380d)
> │ entity_key = −154,304,236,417,689,186 (0xfddbcd1d50fc599e)
> │
> ├── cp_diskserver_v (se @ 0xffffff80fa4456c0) PID 1230, depth=0
> │ vruntime = 12,753,429,279
> │ entity_key = +1,846,538,400 (0x6e0ff0a0)
>
> ── child top-app cfs_rq (0xffffff808ae3aa00) zero_vruntime = 1,355,080,745 (0x50c4e429)
> nr_queued=1
> │
> └── [cfs.curr] Jit thread pool (se @ 0xffffff80dca300c0) PID 1080, depth=1
> parent → 0xffffff808ae3ba00
> vruntime = 1,715,893,071
> entity_key = +360,812,326 (0x15818f26)
> (cpu3 rq->curr is "Jit thread pool")
>
> - cfs_rq of cpu3
> crash-arm64_v9.0.0_k618> cfs_rq.h_nr_runnable,sum_w_vruntime,sum_weight,zero_vruntime 0xffffff8176720840
> h_nr_runnable = 2,
> sum_w_vruntime = 2317754027757,
> sum_weight = 1255,
> zero_vruntime = 10906890879,
>
> - sched_entity of cpu3 top-app cgroup
> crash-arm64_v9.0.0_k618> sched_entity.deadline,vruntime,on_rq,vprot,vlag,slice,load 0xffffff808ae3ba00
> deadline = 8715622320990,
> vruntime = 18292439848198753309,
> on_rq = 1 '\001',
> vprot = 154304236428637793
> vlag = 154304236428637793,
> slice = 2800000,
> load = {
> weight = 46,
> inv_weight = 2147483647
> },
>
> vruntime and vlag abnormal, The vruntime exception is caused by the vlag exception.
This question happen on android17-6.18, fix patch
https://android-review.googlesource.com/c/kernel/common/+/4103883.
Hello Prateek,
On 5/14/2026 11:19 PM, K Prateek Nayak wrote:
> Hello Chen,
>
> On 5/14/2026 6:55 PM, Chen Jinghuang wrote:
>> Hi all,
>>
>> While analyzing cgroup weight adjustment scenarios in EEVDF, I observed a
>> potential vruntime underflow issue caused by unconstrained vlag scaling in
>> rescale_entity(). I would like to consult the community on whether this
>> behavior is expected or if it represents a bug in the current implementation.
>>
>> I notice this my trace in a multi-level cgroup environment:
>>
>> CPU 3
>> CURRENT: PID: 12485 TASK: ffff003027f49440 COMMAND: "cpu_sim"
>> ROOT_TASK_GROUP: ffffd714095439c0 CFS_RQ: ffff002fbfa3d140
>> TASK_GROUP: ffff00211fdfe800 CFS_RQ: ffff00213f2c9800 <throttle_test>
>> TASK_GROUP: ffff20300f2e7000 CFS_RQ: ffff0021190ca000 <case_cpu_idle>
>> TASK_GROUP: ffff203016880c00 CFS_RQ: ffff00211ece4c00 <child_1>
>> [120] PID: 12485 TASK: ffff003027f49440 COMMAND: "cpu_sim" [CURRENT]
>> TASK_GROUP: ffff203016884000 CFS_RQ: ffff002156835c00 <child_2>
>> [120] PID: 12649 TASK: ffff003027f4e540 COMMAND: "cpu_sim"
>>
>> Trace Metrics (Before/After rescale_entity and update_load_set):
>>
>> Before: weight: 209715, avruntime: 7738112562, vlag: 3638691801, vruntime: 4099420761
>> After: weight: 614, avruntime: 7738112562, vlag: 1242814741118, vruntime: 4099420761, limit: 724001488558
>> (vruntime/avruntime stay unchanged; the scaling only touches vlag, deadline, and vprot)
>>
>> Weight drop (209715->614) during __sched_group_set_shares() causes se->vlag
>> to explode in rescale_entity(), surged from 3638691801 to 1242814741118.
>>
>> When the entity's vruntime is subsequently updated via se->vruntime =
>> avruntime - se->vlag, the massive vlag value leads to a underflow of
>> se->vruntime.
>>
>> Furthermore, I noticed that while entity_lag() typically applies a limit (calculated
>> as 724001488558 in this instance) to constrain se->vlag, rescale_entity() performs
>> the scaling without any such boundary checks. This allows se->vlag to exceed the
>> theoretical limits expected by the EEVDF algorithm.
>
> The vlag, to begin with, would be within theoretical limits right?
> Rescaling it should also put it under theoretical limits if I'm not
> wrong.
>
>>
>> Questions:
>> 1. Is this se->vruntime underflow during drastic weight reduction considered acceptable
>> within the current EEVDF design?
>
> All the vruntime considerations use signed delta from the zero_vruntime
> so based on my understanding, it should be fine.
>
>> 2. Should rescale_entity() apply a limit check (similar to entity_lag()) immediately
>> after scaling the vlag to prevent it from escaping reasonable bounds?
>>
>> Something like this?
>>
>> Signed-off-by: Chen Jinghuang <chenjinghuang2@huawei.com>
>> ---
>> kernel/sched/fair.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 3ebec186f982..351e2f7b4b28 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -4046,6 +4046,15 @@ rescale_entity(struct sched_entity *se, unsigned long weight, bool rel_vprot)
>> */
>> se->vlag = div64_long(se->vlag * old_weight, weight);
>
> This vlag is already calculated using entity_lag() which is within the
> theoretical limits and is being scaled proportionally.
>
>>
>> + {
>> + u64 max_slice = cfs_rq_max_slice(cfs_rq_of(se)) + TICK_NSEC;
>
> This should also consider if "se" has the largest slice since it is
> outside of the cfs_rq at this point.
>
>> + s64 limit;
>> +
>> + limit = calc_delta_fair(max_slice, se);
>
> update_load_set() is done after rescale_entity(). The above should
> actually scale the limits based on the new weight.
>
In the trace data I recorded above, the limit = 724001488558 was computed by calc_delta_fair after
se was scaled by update_load_set(), like this
+ rescale_entity(se, weight, rel_vprot);
+
+ update_load_set(&se->load, weight);
+
+ dl_record(se, cfs_rq, 1, _RET_IP_);
dl_record() can capture the values of vlag, vruntime, limit and other data at the time of recording.
The scaled se->vlag after rescale_entity() is 1242814741118, which does not fall within the expected range
defined by the corresponding limit calculated for that se.
>> +
>> + se->vlag = clamp(se->vlag, -limit, limit);
>
> If we use the updated weight, se->vlag should already be within
> those limits.
>
Currently, the calculation of limit is misplaced. Move it after update_load_set() to ensure it is calculated
right after the weights for se are updated.
The correvted code is as follows:
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 351e2f7b4b28..eb273a9047f1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4104,6 +4104,11 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
update_load_set(&se->load, weight);
+ u64 max_slice = cfs_rq_max_slice(cfs_rq) + TICK_NSEC;
+ s64 limit = calc_delta_fair(max_slice, se);
+
+ se->vlag = clamp(se->vlag, -limit, limit);
+
do {
u32 divider = get_pelt_divider(&se->avg);
se->avg.load_avg = div_u64(se_weight(se) * se->avg.load_sum, divider);
>> + }
>> +
>> /*
>> * DEADLINE
>> * --------
>
© 2016 - 2026 Red Hat, Inc.