On Mon, Aug 10, 2015 at 01:47:06PM +0200, Peter Zijlstra wrote: > On Mon, Aug 10, 2015 at 03:08:59PM +0900, byungchul.p...@lge.com wrote: > > From: Byungchul Park <byungchul.p...@lge.com> > > > > in addition, "#ifdef CONFIG_SMP" is removed becasuse we need to sync a > > se's load with its cfs_rq even in the case of !SMP. remember it is possible > > to move between groups in *a* cpu.
if it never need to keep the blocked load in the case of !SMP, then i will undo this part, and add "#ifdef" to my additional code. commit message below is for explaining the reason why i removed some comments. not much about code work. > > > > i also removed some comments mentioning migration_task_rq_fair(). > > migration_task_rq_fair() can be called in three cases. and in each case, > > both decay counter and blocked load are already considered. so we > > don't need to consider these in task_move_group_fair() at all. > > > > 1. the wake-up migration case > > enqueue_entity_load_avg() makes se->avg.decay_count zero after applying it. > > and it will be woken up soon so we don't need to add its load to > > cfs_rq->blocked_load_avg. > > > > 2. the fork balancing case > > se->avg.decay_count is initialized in __sched_fork() to zero. and > > wake_up_new_task() calls activate_task() with flag = 0 so that > > enqueue_entity_load_avg() can omit adding its load to > > cfs_rq->blocked_load_avg, and it will be woken up soon. > > > > 3. the rq migration case (not wake up case) > > the target task is already on rq, so we don't need to consider both its > > decay counter and blocked load in this case. > > > > Signed-off-by: Byungchul Park <byungchul.p...@lge.com> > > What code is this against? Please look at current code and try again. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/