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: Peter Williams <pwil3058@bigpond.net.au>

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
   -- Ambrose Bierce