Messages in this thread Patch in this message | | | Date | Fri, 23 Nov 2001 13:05:30 +0100 (CET) | From | Ingo Molnar <> | Subject | [patch] 2.4.15, PROC_CHANGE_PENALTY fix |
| |
noticed another (more or less minor) SMP scheduler bug, affecting HZ != 100 kernels. (such as the default Alpha kernel, or some x86 'low latency' kernel compilations used by some of us.).
If HZ != 100 then PROC_CHANGE_PENALTY does not get scaled along the size of ->counter ticks. The effect of this bug on SMP Alpha is that the 'effecive' PROC_CHANGE_PENALTY of 20 (on Alpha) is degraded to a comparable value of 2, which is *very* bad for SMP affinity. On x86, this value is 15.
The solution is to scale the PROC_CHANGE_PENALTY value via TICK_SCALE. I've added a *4 to it so that the 'traditional' (and more intuitive) value of 15 can be used on x86. Or we could change the value of PROC_CHANGE_PENALTY to be 60 on x86 and leave out the *4.
it would be nice to see whether anyone with access to an SMP/Alpha box could confirm that this patch impacts things like kernel compilation speed or other cache-intensive and affinity-sensitive applications.
Ingo --- linux/kernel/sched.c.orig Wed Nov 21 10:58:56 2001 +++ linux/kernel/sched.c Wed Nov 21 10:59:37 2001 @@ -172,7 +172,7 @@ /* Give a largish advantage to the same processor... */ /* (this is equivalent to penalizing other processors) */ if (p->processor == this_cpu) - weight += PROC_CHANGE_PENALTY; + weight += TICK_SCALE(PROC_CHANGE_PENALTY*4); #endif /* .. and a slight advantage to the current MM */
| |