]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
sched/fair: Rename cfs_rq::avg_load to cfs_rq::sum_weight
authorIngo Molnar <mingo@kernel.org>
Wed, 26 Nov 2025 11:09:16 +0000 (12:09 +0100)
committerIngo Molnar <mingo@kernel.org>
Mon, 15 Dec 2025 06:52:44 +0000 (07:52 +0100)
commit4ff674fa986c27ec8a0542479258c92d361a2566
tree48414b93d7c4a8c803beab19ee01e74bd60b3351
parent80390ead2080071cbd6f427ff8deb94d10a4a50f
sched/fair: Rename cfs_rq::avg_load to cfs_rq::sum_weight

The ::avg_load field is a long-standing misnomer: it says it's an
'average load', but in reality it's the momentary sum of the load
of all currently runnable tasks. We'd have to also perform a
division by nr_running (or use time-decay) to arrive at any sort
of average value.

This is clear from comments about the math of fair scheduling:

    *              \Sum w_i := cfs_rq->avg_load

The sum of all weights is ... the sum of all weights, not
the average of all weights.

To make it doubly confusing, there's also an ::avg_load
in the load-balancing struct sg_lb_stats, which *is* a
true average.

The second part of the field's name is a minor misnomer
as well: it says 'load', and it is indeed a load_weight
structure as it shares code with the load-balancer - but
it's only in an SMP load-balancing context where
load = weight, in the fair scheduling context the primary
purpose is the weighting of different nice levels.

So rename the field to ::sum_weight instead, which makes
the terminology of the EEVDF math match up with our
implementation of it:

    *              \Sum w_i := cfs_rq->sum_weight

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20251201064647.1851919-6-mingo@kernel.org
kernel/sched/fair.c
kernel/sched/sched.h