* 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
