Re: weakness of runnable load tracking?

[Alex Shi]

>> Hi Paul & Ingo:
>>
>> In a short word of this issue: burst forking/waking tasks have no time
>> accumulate the load contribute, their runnable load are taken as zero.
>> that make select_task_rq do a wrong decision on which group is idlest.
> 
> So these aren't strictly comparable; bursting and forking tasks have
> fairly different characteristics here.

Many thanks for looking into this. :)
> 
> When we fork a task we intentionally reset the previous history.  This
> means that a forked task that immediately runs is going to show up as
> 100% runnable and then converge to it's true value.  This was fairly
> intentionally chosen so that tasks would "start" fast rather than
> having to worry about ramp up.

I am sorry for didn't see the 100% runnable for a new forked task. 
I believe the code need the following patch to initialize decay_count, 
and load_avg_contrib. otherwise they are random value. 
In enqueue_entity_load_avg() p->se.avg.runnable_avg_sum for new forked 
task is always zero, either because se.avg.last_runnable_update is set
 as clock_task due to decay_count <=0, or just do 
__synchronize_entity_decay not update_entity_load_avg.

===========