Skip to content

Commit 8dafa9d

Browse files
author
Peter Zijlstra
committed
sched/eevdf: Fix min_deadline heap integrity
Marek and Biju reported instances of: "EEVDF scheduling fail, picking leftmost" which Mike correlated with cgroup scheduling and the min_deadline heap getting corrupted; some trace output confirms: > And yeah, min_deadline is hosed somehow: > > validate_cfs_rq: --- / > __print_se: ffff88845cf48080 w: 1024 ve: -58857638 lag: 870381 vd: -55861854 vmd: -66302085 E (11372/tr) > __print_se: ffff88810d165800 w: 25 ve: -80323686 lag: 22336429 vd: -41496434 vmd: -66302085 E (-1//autogroup-31) > __print_se: ffff888108379000 w: 25 ve: 0 lag: -57987257 vd: 114632828 vmd: 114632828 N (-1//autogroup-33) > validate_cfs_rq: min_deadline: -55861854 avg_vruntime: -62278313462 / 1074 = -57987256 Turns out that reweight_entity(), which tries really hard to be fast, does not do the normal dequeue+update+enqueue pattern but *does* scale the deadline. However, it then fails to propagate the updated deadline value up the heap. Fixes: 147f3ef ("sched/fair: Implement an EEVDF-like scheduling policy") Reported-by: Marek Szyprowski <[email protected]> Reported-by: Biju Das <[email protected]> Reported-by: Mike Galbraith <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Tested-by: Biju Das <[email protected]> Tested-by: Mike Galbraith <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
1 parent 94f6f05 commit 8dafa9d

File tree

1 file changed

+1
-0
lines changed

1 file changed

+1
-0
lines changed

kernel/sched/fair.c

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3613,6 +3613,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
36133613
*/
36143614
deadline = div_s64(deadline * old_weight, weight);
36153615
se->deadline = se->vruntime + deadline;
3616+
min_deadline_cb_propagate(&se->run_node, NULL);
36163617
}
36173618

36183619
#ifdef CONFIG_SMP

0 commit comments

Comments
 (0)