• Peter Williams's avatar
    sched: fix bug in balance_tasks() · a4ac01c3
    Peter Williams authored
    There are two problems with balance_tasks() and how it used:
    
    1. The variables best_prio and best_prio_seen (inherited from the old
    move_tasks()) were only required to handle problems caused by the
    active/expired arrays, the order in which they were processed and the
    possibility that the task with the highest priority could be on either.
      These issues are no longer present and the extra overhead associated
    with their use is unnecessary (and possibly wrong).
    
    2. In the absence of CONFIG_FAIR_GROUP_SCHED being set, the same
    this_best_prio variable needs to be used by all scheduling classes or
    there is a risk of moving too much load.  E.g. if the highest priority
    task on this at the beginning is a fairly low priority task and the rt
    class migrates a task (during its turn) then that moved task becomes the
    new highest priority task on this_rq but when the sched_fair class
    initializes its copy of this_best_prio it will get the priority of the
    original highest priority task as, due to the run queue locks being
    held, the reschedule triggered by pull_task() will not have taken place.
      This could result in inappropriate overriding of skip_for_load and
    excessive load being moved.
    
    The attached patch addresses these problems by deleting all reference to
    best_prio and best_prio_seen and making this_best_prio a reference
    parameter to the various functions involved.
    
    load_balance_fair() has also been modified so that this_best_prio is
    only reset (in the loop) if CONFIG_FAIR_GROUP_SCHED is set.  This should
    preserve the effect of helping spread groups' higher priority tasks
    around the available CPUs while improving system performance when
    CONFIG_FAIR_GROUP_SCHED isn't set.
    Signed-off-by: default avatarPeter Williams <pwil3058@bigpond.net.au>
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    a4ac01c3
sched_rt.c 5.23 KB