On 06/17/2013 07:51 PM, Paul Turner wrote: > Can you add something like: > > + /* > + * Task re-woke on same cpu (or else > migrate_task_rq_fair() > + * would have made count negative); we must be careful > to avoid > + * double-accounting blocked time after synchronizing > decays. > + */ > > > Reviewed-by: Paul Turner <[email protected]>
thanks for review! --- >From 24d9b43e7a269e6ffee5b874d39812b83812a809 Mon Sep 17 00:00:00 2001 From: Alex Shi <[email protected]> Date: Thu, 9 May 2013 10:54:13 +0800 Subject: [PATCH] sched: fix slept time double counting in enqueue entity The wakeuped migrated task will __synchronize_entity_decay(se); in migrate_task_fair, then it needs to set `se->avg.last_runnable_update -= (-se->avg.decay_count) << 20' before update_entity_load_avg, in order to avoid slept time is updated twice for se.avg.load_avg_contrib in both __syncchronize and update_entity_load_avg. but if the slept task is waked up from self cpu, it miss the last_runnable_update before update_entity_load_avg(se, 0, 1), then the slept time was used twice in both functions. So we need to remove the double slept time counting. Signed-off-by: Alex Shi <[email protected]> Reviewed-by: Paul Turner <[email protected]> --- kernel/sched/fair.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index df5b8a9..1e5a5e6 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1571,7 +1571,13 @@ static inline void enqueue_entity_load_avg(struct cfs_rq *cfs_rq, } wakeup = 0; } else { - __synchronize_entity_decay(se); + /* + * Task re-woke on same cpu (or else migrate_task_rq_fair() + * would have made count negative); we must be careful to avoid + * double-accounting blocked time after synchronizing decays. + */ + se->avg.last_runnable_update += __synchronize_entity_decay(se) + << 20; } /* migrated tasks did not contribute to our blocked load */ -- 1.7.5.4 -- 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/
