lkml.org 
[lkml]   [2001]   [Nov]   [23]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
DateFri, 23 Nov 2001 13:05:30 +0100 (CET)
FromIngo 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 */
\
 
 \ /
  Last update: 2005-03-22 12:13    [W:0.134 / U:0.510 seconds]
©2003-2008 Jasper Spaans