[PATCH] Use cache_decay_ticks instead of a constant

This patch, based on Ken Chen's patch, changes the default 2.5 msec
migration-cutoff value to be based on cache_decay_ticks, which is what
we used for a long time prior the sched-domains code.  (If an
architecture does not set cache_decay_ticks then 2.5 msec is used.)

This causes the following new migration-cutoff values on various SMP
systems:

 x86, variable:

 2-way celeron 466MHz, 128K:        2.5 msec ->  1.0 msec
 2-way/4-way 2.2 GHz P4 Xeon 1MB:   2.5 msec ->  2.0 msec
 8-way P3 700 MHz Xeon 2MB:         2.5 msec ->  6.0 msec

 x64, variable:

 amd64: 2.0 GHz, 1MB:               2.5 msec -> 1.5 msec
 em64t: 3.4 GHz, 1MB:               2.5 msec -> 3.0 msec

 ppc64 [*]:                         2.5 msec -> 2.5 msec (constant)

 ia64:                              2.5 msec -> 10.0 msec (constant)

    [*] ppc64 does not set cache_decay_ticks so we fall back to the
        default.

I believe in light of previous testing we could attempt this for 2.6.9 as
well.  (Note: that the 2.6.9-rc3 patch looks similar but needs to patch
kernel/sched.c.  Note2: this patch is different from Ken's original one.)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

kernel/sched.c

@@ -388,7 +388,7 @@ struct sched_domain {
 	.max_interval		= 4,			\
 	.busy_factor		= 64,			\
 	.imbalance_pct		= 125,			\
-	.cache_hot_time		= (5*1000000/2),	\
+	.cache_hot_time		= cache_decay_ticks*1000000 ? : (5*1000000/2),\
 	.cache_nice_tries	= 1,			\
 	.per_cpu_gain		= 100,			\
 	.flags			= SD_BALANCE_NEWIDLE	\