sched: reset blocked load decay_count during synchronization
authorChris Redpath <chris.redpath@arm.com>
Mon, 23 Feb 2015 06:24:16 +0000 (15:24 +0900)
committerSeung-Woo Kim <sw0312.kim@samsung.com>
Wed, 14 Dec 2016 04:41:54 +0000 (13:41 +0900)
commit79850af1eae6c30630e11b7a7e2ecaffd7519307
tree0855c763d79e6535677f031236db43bb2a2eea8e
parentc23c68b12997dcfa6eea6f039e5772b4a10fb891
sched: reset blocked load decay_count during synchronization

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 <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
[k.kozlowski: rebased on 4.1, no signed-off-by of previous committer]
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
kernel/sched/fair.c