Messages in this thread Patch in this message | | | Date | Thu, 22 Jan 2004 22:31:40 -0800 | From | "Martin J. Bligh" <> | Subject | [PATCH] clarify find_busiest_group |
| |
Fix a minor nit with the find_busiest_group code. No functional change, but makes the code simpler and clearer. This patch does two things ... adds some more expansive comments, and removes this if clause:
if (*imbalance < SCHED_LOAD_SCALE && max_load - this_load > SCHED_LOAD_SCALE) *imbalance = SCHED_LOAD_SCALE;
If we remove the scaling factor, we're basically conditionally doing:
if (*imbalance < 1) *imbalance = 1;
Which is pointless, as the very next thing we do is to remove the scaling factor, rounding up to the nearest integer as we do:
*imbalance = (*imbalance + SCHED_LOAD_SCALE - 1) >> SCHED_LOAD_SHIFT;
Thus the if statement is redundant, and only makes the code harder to read ;-)
M.
diff -aurpN -X /home/fletch/.diff.exclude mm5/kernel/sched.c mm5-find_busiest_group/kernel/sched.c --- mm5/kernel/sched.c Wed Jan 21 22:07:11 2004 +++ mm5-find_busiest_group/kernel/sched.c Thu Jan 22 22:21:22 2004 @@ -1440,11 +1440,16 @@ nextgroup: if (idle == NOT_IDLE && 100*max_load <= domain->imbalance_pct*this_load) goto out_balanced; - /* Take the minimum possible imbalance. */ + /* + * We're trying to get all the cpus to the average_load, so we don't + * want to push ourselves above the average load, nor do we wish to + * reduce the max loaded cpu below the average load, as either of these + * actions would just result in more rebalancing later, and ping-pong + * tasks around. Thus we look for the minimum possible imbalance. + */ *imbalance = min(max_load - avg_load, avg_load - this_load); - if (*imbalance < SCHED_LOAD_SCALE - && max_load - this_load > SCHED_LOAD_SCALE) - *imbalance = SCHED_LOAD_SCALE; + + /* Get rid of the scaling factor now, rounding *up* as we divide */ *imbalance = (*imbalance + SCHED_LOAD_SCALE - 1) >> SCHED_LOAD_SHIFT; if (*imbalance == 0) { - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |