lkml.org 
[lkml]   [2014]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2 v4] sched: Rewrite per entity runnable load average tracking
    On Tue, Jul 29, 2014 at 03:35:10PM +0200, Peter Zijlstra wrote:
    > On Tue, Jul 29, 2014 at 09:53:44AM +0800, Yuyang Du wrote:
    > > On Tue, Jul 29, 2014 at 11:39:11AM +0200, Peter Zijlstra wrote:
    > > > > > For task, assuming its load.weight does not change much, yes, we can. But in theory, task's
    > > > >
    > > > > I would even say that the load_avg of a task should not be impacted by
    > > > > an old priority value. Once, the priority of a task is changed, we
    > > > > should only take into account this new priority to weight the load_avg
    > > > > of the task
    > > >
    > > > So for tasks I would immediately agree, and I think for groups too,
    > > > seeing how the group weight is based off of this avg, if you then
    > > > include the old weight we'll get a feedback loop. This might not be
    > > > desired as it would counteract the SMP movement of tasks.
    > >
    > > Including the old weight can we get the *right* feedback. Because say until
    > > weight is changed, we are balanced, changed weight leads to imbalance. Without
    > > old weight, the imbalance is multiplied by the history, like we have never been
    > > balanced.
    >
    > 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.

    3 of course.

    > 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.


    \
     
     \ /
      Last update: 2014-07-29 18:41    [W:4.665 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site