aboutsummaryrefslogtreecommitdiffstats
path: root/rust/helpers/xarray.c
diff options
context:
space:
mode:
authorPeter Zijlstra <[email protected]>2025-01-28 14:39:49 +0000
committerPeter Zijlstra <[email protected]>2025-04-16 19:09:12 +0000
commitc70fc32f44431bb30f9025ce753ba8be25acbba3 (patch)
treeca2cbb94f5d37f2fa17ff57f8503f42f4c3abf60 /rust/helpers/xarray.c
parentsched/debug: Print the local group's asym_prefer_cpu (diff)
downloadkernel-c70fc32f44431bb30f9025ce753ba8be25acbba3.tar.gz
kernel-c70fc32f44431bb30f9025ce753ba8be25acbba3.zip
sched/fair: Adhere to place_entity() constraints
Mike reports that commit 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") relies on commit 4423af84b297 ("sched/fair: optimize the PLACE_LAG when se->vlag is zero") to not trip a WARN in place_entity(). What happens is that the lag of the very last entity is 0 per definition -- the average of one element matches the value of that element. Therefore place_entity() will match the condition skipping the lag adjustment: if (sched_feat(PLACE_LAG) && cfs_rq->nr_queued && se->vlag) { Without the 'se->vlag' condition -- it will attempt to adjust the zero lag even though we're inserting into an empty tree. Notably, we should have failed the 'cfs_rq->nr_queued' condition, but don't because they didn't get updated. Additionally, move update_load_add() after placement() as is consistent with other place_entity() users -- this change is non-functional, place_entity() does not use cfs_rq->load. Fixes: 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reported-by: Mike Galbraith <[email protected]> Signed-off-by: "Peter Zijlstra (Intel)" <[email protected]> Signed-off-by: Mike Galbraith <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'rust/helpers/xarray.c')
0 files changed, 0 insertions, 0 deletions