Xunlei Pang <[email protected]> writes: > In __synchronize_entity_decay(), if "decays" happens to be zero, > se->avg.decay_count will not be zeroed, holding the positive value > assigned when dequeued last time. > > This is problematic in the following case: > If this runnable task is CFS-balanced to other CPUs soon afterwards, > migrate_task_rq_fair() will treat it as a blocked task due to its > non-zero decay_count, thereby adding its load to cfs_rq->removed_load > wrongly. > > Thus, we must zero se->avg.decay_count in this case as well.
Yep. We probably didn't notice this because migrate will happen to clear this by doing decay_count = -__synch(), but you can hit this via switched_from_fair or just on enqueue followed by a load-balance migration that thinks decay_counter was zero due to being on_rq. > > Signed-off-by: Xunlei Pang <[email protected]> Reviewed-by: Ben Segall <[email protected]> > --- > kernel/sched/fair.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index df2cdf7..ea517cd 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -2574,11 +2574,11 @@ static inline u64 __synchronize_entity_decay(struct > sched_entity *se) > u64 decays = atomic64_read(&cfs_rq->decay_counter); > > decays -= se->avg.decay_count; > + se->avg.decay_count = 0; > if (!decays) > return 0; > > se->avg.load_avg_contrib = decay_load(se->avg.load_avg_contrib, decays); > - se->avg.decay_count = 0; > > return decays; > } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
