[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>
Showing
Please register or sign in to comment