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 [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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]
