Re: [PATCH 2/2 v4] sched: Rewrite per entity runnable load average tracking

[Yuyang Du <yuyang.du@intel.com>]

On Tue, Jul 29, 2014 at 03:35:10PM +0200, Peter Zijlstra wrote:
> 
> Does not compute, sorry. How would delaying the effect of migrations
> help?
> 
> Suppose we have 2 cpus and 6 tasks. cpu0 has 2 tasks, cpu1 has 4 tasks.
> the group weights are resp. 341 and 682. We compute we have an imbalance
> of 341 and need to migrate 170 to equalize. We achieve this by moving
> the 1 task, such that both cpus end up with 4 tasks.
> 
> After that we want to find weights of 512 and 512. But if we were to
> consider old weights, we'd find 426 and 597 making it appear there is
> still an imbalance. We could end up migrating more, only to later find
> we overshot and now need to go back.
> 
> This is the classical ringing problem.
> 
> I also don't see any up-sides from doing this.

I am not sure I understand your example, but it seems it is group weight
distribution. Since in migration, we migrate the load with task, 170 will be
utterly moved. So the new weight/share distribution would be immediate
512 and 512.

But for the group entity's parent cfs_rq in terms of how this group entity
contributes to load in the infinite decaying series, it would be
e.g., 341 and before, migration, then 512 thereafter.

Hope this graph helps:

CPU1 <--> cfs_rq1                         CPU2 <--> cfs_rq2
             |                                         |
      |------------|                            |------------|
tsk_entity1   tg_entity1 <--> tg_cfs_rq1  tsk_entity2   tg_entity2 <--> tg_cfs_rq2
                                  |                                         |
                            tsk_entity3                               tsk_entity4

Then On CPU1:

cfs_rq1->avg.load_avg = tsk_entity1->avg.load_avg + tg_entity1->avg.load_avg

tg_cfs_rq1->avg.load_avg = tsk_entity3->avg.load_avg

tg_entity1's weight = tg_cfs_rq1->avg.load_avg / (tg_cfs_rq1->avg.load_avg + tg_cfs_rq2->avg.load_avg)

Same for things on CPU2.