On Fri, Feb 15, 2013 at 2:07 AM, Alex Shi <[email protected]> wrote: > >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index 1dff78a..9d1c193 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -1557,8 +1557,8 @@ static void __sched_fork(struct task_struct *p) >> * load-balance). >> */ >> #if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED) >> - p->se.avg.runnable_avg_period = 0; >> - p->se.avg.runnable_avg_sum = 0; >> + p->se.avg.runnable_avg_period = 1024; >> + p->se.avg.runnable_avg_sum = 1024; > > It can't work. > avg.decay_count needs to be set to 0 before enqueue_entity_load_avg(), then > update_entity_load_avg() can't be called, so, runnable_avg_period/sum > are unusable.
Well we _could_ also use a negative decay_count here and treat it like a migration; but the larger problem is the visibility of p->on_rq; which is gates whether we account the time as runnable and occurs after activate_task() so that's out. > > Even we has chance to call __update_entity_runnable_avg(), > avg.last_runnable_update needs be set before that, usually, it needs to > be set as 'now', that cause __update_entity_runnable_avg() function > return 0, then update_entity_load_avg() still can not reach to > __update_entity_load_avg_contrib(). > > If we embed a simple new task load initialization to many functions, > that is too hard for future reader. This is my concern about making this a special case with the introduction ENQUEUE_NEWTASK flag; enqueue jumps through enough hoops as it is. I still don't see why we can't resolve this at init time in __sched_fork(); your patch above just moves an explicit initialization of load_avg_contrib into the enqueue path. Adding a call to __update_task_entity_contrib() to the previous alternate suggestion would similarly seem to resolve this? > >> #endif >> #ifdef CONFIG_SCHEDSTATS >> memset(&p->se.statistics, 0, sizeof(p->se.statistics)); >> >> >> >>> >>> >>> -- >>> Thanks >>> Alex > > > -- > Thanks > Alex -- 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/
