lkml.org 
[lkml]   [2001]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
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 */
\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.033 / U:2.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site