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 <[email protected]>
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
* Peter Williams <[email protected]> wrote:
> 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).
indeed.
> 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.
looks good to me - i've applied your fixes to my tree. (I'll give it a
good workout to see if there's any negative impact on the quality
balancing.)
Ingo