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
This archive was generated by hypermail 2b29 : Fri Nov 23 2001 - 21:00:33 EST