Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Peter Zijlstra <peterz@infradead.org>
Date: 2010-01-20 20:49:18
Also in:
lkml
On Wed, 2010-01-20 at 14:04 -0600, Joel Schopp wrote:
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads there is performance benefit to idling the higher numbered threads in the core.
So this is an actual performance improvement, not only power savings?
quoted hunk ↗ jump to hunk
This patch implements arch_scale_smt_power to dynamically update smt thread power in these idle cases in order to prefer threads 0,1 over threads 2,3 within a core. Signed-off-by: Joel Schopp <redacted> --- Index: linux-2.6.git/arch/powerpc/kernel/smp.c ===================================================================--- linux-2.6.git.orig/arch/powerpc/kernel/smp.c +++ linux-2.6.git/arch/powerpc/kernel/smp.c@@ -617,3 +617,44 @@ void __cpu_die(unsigned int cpu) smp_ops->cpu_die(cpu); } #endif + +static inline int thread_in_smt4core(int x) +{ + return x % 4; +} +unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu) +{ + int cpu2; + int idle_count = 0; + + struct cpumask *cpu_map = sched_domain_span(sd); + + unsigned long weight = cpumask_weight(cpu_map); + unsigned long smt_gain = sd->smt_gain; + + if (cpu_has_feature(CPU_FTRS_POWER7) && weight == 4) { + for_each_cpu(cpu2, cpu_map) { + if (idle_cpu(cpu2)) + idle_count++; + } + + /* the following section attempts to tweak cpu power based + * on current idleness of the threads dynamically at runtime + */ + if (idle_count == 2 || idle_count == 3 || idle_count == 4) { + if (thread_in_smt4core(cpu) == 0 || + thread_in_smt4core(cpu) == 1) { + /* add 75 % to thread power */ + smt_gain += (smt_gain >> 1) + (smt_gain >> 2); + } else { + /* subtract 75 % to thread power */ + smt_gain = smt_gain >> 2; + } + } + } + /* default smt gain is 1178, weight is # of SMT threads */ + smt_gain /= weight; + + return smt_gain; + +}
This looks to suffer significant whitespace damage. The design goal for smt_power was to be able to actually measure the processing gains from smt and feed that into the scheduler, not really placement tricks like this. Now I also heard AMD might want to have something similar to this, something to do with powerlines and die layout. I'm not sure playing games with cpu_power is the best or if simply moving tasks to lower numbered cpus using an SD_flag is the best solution for these kinds of things.
quoted hunk ↗ jump to hunk
Index: linux-2.6.git/kernel/sched_features.h ===================================================================--- linux-2.6.git.orig/kernel/sched_features.h +++ linux-2.6.git/kernel/sched_features.h@@ -107,7 +107,7 @@ SCHED_FEAT(CACHE_HOT_BUDDY, 1) /* * Use arch dependent cpu power functions */ -SCHED_FEAT(ARCH_POWER, 0) +SCHED_FEAT(ARCH_POWER, 1) SCHED_FEAT(HRTICK, 0) SCHED_FEAT(DOUBLE_TICK, 0)
And you just wrecked x86 ;-) It has an smt_power implementation that tries to measure smt gains using aperf/mperf, trouble is that this represents the actual performance not the capacity. This has the problem that when idle it represents 0 capacity and will not attract work. Coming up with something that actually works there is on the todo list, I was thinking perhaps temporal maximums from !idle. So if you want to go with this, you'll need to stub out arch/x86/kernel/cpu/sched.c