Re: [PATCH] sched: fix evaluation of skip_for_load in move_tasks()

[Peter Williams <pwil3058@bigpond.net.au>]

Siddha, Suresh B wrote:
> On Wed, Apr 26, 2006 at 09:23:32AM +1000, Peter Williams wrote:
>> Siddha, Suresh B wrote:
>>> I think we need to change this to
>>> 	if (skip_for_load && idx < this_best_prio && idx == busiest_best_prio)
>>> 		skip_for_load = !busiest_best_prio_seen;
>>>
>>> Otherwise we will reset skip_for_load to '0' even for the tasks whose prio is 
>>> less than this_best_prio but not equal to busiest_best_prio.
>> And why is that a problem?  The intention of this code is to make sure 
>> at least one busiest_best_prio task doesn't get moved as a result of the 
>> "skip for reasons of load weight" mechanism being overridden by the "idx 
>> < this_best_prio" exception.  I can't see how this intention is being 
>> subverted.
> 
> There might be scenarios where we will endup moving other priority tasks(
> not those with busiest_best_prio) which will still become highest priority
> on new queue. This may or may not be bad. But this was not our intention
> with the intended code, right?

I considered this (as part of the original code to allow override of the 
skip for cases where moving a task will make it the best priority on the 
CPU -- NB no extra caveats about finding the best priority task which 
meets the criteria) and decided that it wasn't worth worrying about as 
the complexity of the code required to handle it would be considerable.

Also, because we are actually moving a bigger load than is required to 
balance the total weighted loads on the two queues, there's an argument 
that we should move the smallest one that meets the requirement.  With 
these conflicting arguments, it seems best just to move the first one we 
find that meets the criteria and is movable.

Load balancing is probabilistic at best and extra effort trying to be 
perfect will be wasted.  This is even more the case when you take into 
account the fact that as soon as you release the locks on the queues 
everything is highly likely to change anyway.

I figured that this code is consistent with the original load balancing 
code in this regard.

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

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