Chris Redpath <[email protected]> writes: > If an entity happens to sleep for less than one tick duration > the tracked load associated with that entity can be decayed by an > unexpectedly large amount if it is later migrated to a different > CPU. This can interfere with correct scheduling when entity load > is used for decision making. > > The reason for this is that when an entity is dequeued and enqueued > quickly, such that se.avg.decay_count and cfs_rq.decay_counter > do not differ when that entity is enqueued again, > __synchronize_entity_decay skips the calculation step and also skips > clearing the decay_count. At a later time that entity may be > migrated and its load will be decayed incorrectly. > > All users of this function expect decay_count to be zero'ed after > use. > > Signed-off-by: Chris Redpath <[email protected]> Reviewed-by: Ben Segall <[email protected]>
> --- > kernel/sched/fair.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index e8b652e..b7e5945 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -2142,12 +2142,10 @@ static inline u64 __synchronize_entity_decay(struct > sched_entity *se) > u64 decays = atomic64_read(&cfs_rq->decay_counter); > > decays -= se->avg.decay_count; > - if (!decays) > - return 0; > - > - se->avg.load_avg_contrib = decay_load(se->avg.load_avg_contrib, decays); > + if (decays) > + 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/
