| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1326099367-4166-1-git-send-email-youquan.song@intel.com> Date: Mon, 9 Jan 2012 16:56:07 +0800 From: Youquan Song <youquan.song@...el.com> To: linux-kernel@...r.kernel.org, mingo@...e.hu, a.p.zijlstra@...llo.nl, tglx@...utronix.de, hpa@...or.com, akpm@...ux-foundation.org Cc: stable@...r.kernel.org, suresh.b.siddha@...el.com, arjan@...ux.intel.com, len.brown@...el.com, anhua.xu@...el.com, chaohong.guo@...el.com, Youquan Song <youquan.song@...ux.intel.com>, Youquan Song <youquan.song@...el.com> Subject: [PATCH] x86,sched: Fix sched_smt_power_savings totally broken sched_smt_power_savings is totally broken at lastest linux and -tip tree. sched_smt_power_savings is set to 1, the scheduler tries to schedule processes on the least number of hyper-threads on a core as possible. In other words, the process load is distributed such that all the hyper-threads in a core and all the cores within the same processor are busy before the load is distributed to other hyper-threads and cores in another processor. Test On Intel Xeon machine with 2 physical CPUs and each CPU has 8 cores / 16 threads. physical CPU 0 includes cpu[0~7] and cpu[16~23]; while physical CPU 1 includes cpu[8~15] and cpu[24~31]. At latest -tip tree: echo 1 > /sys/devices/system/cpu/sched_smt_power_savings ./ebizzy -t 16 -S 100 & sleep 10 ; cat /proc/sched_debug | grep -A 1 cpu# > tmp.log cpu#0, 2693.564 MHz .nr_running : 0 -- cpu#1, 2693.564 MHz .nr_running : 1 -- cpu#2, 2693.564 MHz .nr_running : 0 -- cpu#3, 2693.564 MHz .nr_running : 1 -- cpu#4, 2693.564 MHz .nr_running : 1 -- cpu#5, 2693.564 MHz .nr_running : 1 -- cpu#6, 2693.564 MHz .nr_running : 1 -- cpu#7, 2693.564 MHz .nr_running : 1 -- cpu#8, 2693.564 MHz .nr_running : 1 -- cpu#9, 2693.564 MHz .nr_running : 1 -- cpu#10, 2693.564 MHz .nr_running : 1 -- cpu#11, 2693.564 MHz .nr_running : 0 -- cpu#12, 2693.564 MHz .nr_running : 1 -- cpu#13, 2693.564 MHz .nr_running : 1 -- cpu#14, 2693.564 MHz .nr_running : 0 -- cpu#15, 2693.564 MHz .nr_running : 0 -- cpu#16, 2693.564 MHz .nr_running : 0 -- cpu#17, 2693.564 MHz .nr_running : 0 -- cpu#18, 2693.564 MHz .nr_running : 1 -- cpu#19, 2693.564 MHz .nr_running : 0 -- cpu#20, 2693.564 MHz .nr_running : 0 -- cpu#21, 2693.564 MHz .nr_running : 0 -- cpu#22, 2693.564 MHz .nr_running : 0 -- cpu#23, 2693.564 MHz .nr_running : 0 -- cpu#24, 2693.564 MHz .nr_running : 0 -- cpu#25, 2693.564 MHz .nr_running : 1 -- cpu#26, 2693.564 MHz .nr_running : 1 -- cpu#27, 2693.564 MHz .nr_running : 1 -- cpu#28, 2693.564 MHz .nr_running : 0 -- cpu#29, 2693.564 MHz .nr_running : 0 -- cpu#30, 2693.564 MHz .nr_running : 1 -- cpu#31, 2693.564 MHz .nr_running : 1 >From above, we notice 16 threads are distributed among 2 physical CPUs. After apply the patch, 16 threads are only distributed at one physical CPU. In this case, we can notice 30% power saving. Following are the result after apply the patch: cpu#0, 2693.384 MHz .nr_running : 1 -- cpu#1, 2693.384 MHz .nr_running : 1 -- cpu#2, 2693.384 MHz .nr_running : 1 -- cpu#3, 2693.384 MHz .nr_running : 1 -- cpu#4, 2693.384 MHz .nr_running : 1 -- cpu#5, 2693.384 MHz .nr_running : 1 -- cpu#6, 2693.384 MHz .nr_running : 1 -- cpu#7, 2693.384 MHz .nr_running : 1 -- cpu#8, 2693.384 MHz .nr_running : 0 -- cpu#9, 2693.384 MHz .nr_running : 0 -- cpu#10, 2693.384 MHz .nr_running : 0 -- cpu#11, 2693.384 MHz .nr_running : 0 -- cpu#12, 2693.384 MHz .nr_running : 0 -- cpu#13, 2693.384 MHz .nr_running : 0 -- cpu#14, 2693.384 MHz .nr_running : 0 -- cpu#15, 2693.384 MHz .nr_running : 0 -- cpu#16, 2693.384 MHz .nr_running : 1 -- cpu#17, 2693.384 MHz .nr_running : 1 -- cpu#18, 2693.384 MHz .nr_running : 1 -- cpu#19, 2693.384 MHz .nr_running : 1 -- cpu#20, 2693.384 MHz .nr_running : 1 -- cpu#21, 2693.384 MHz .nr_running : 1 -- cpu#22, 2693.384 MHz .nr_running : 1 -- cpu#23, 2693.384 MHz .nr_running : 1 -- cpu#24, 2693.384 MHz .nr_running : 0 -- cpu#25, 2693.384 MHz .nr_running : 0 -- cpu#26, 2693.384 MHz .nr_running : 0 -- cpu#27, 2693.384 MHz .nr_running : 0 -- cpu#28, 2693.384 MHz .nr_running : 0 -- cpu#29, 2693.384 MHz .nr_running : 0 -- cpu#30, 2693.384 MHz .nr_running : 0 -- cpu#31, 2693.384 MHz .nr_running : 1 This patch will set SMT sibling power capability to SCHED_POWER_SCALE (1024) when sched_smt_power_savings set. So when there is possible do power saving during scheduling, scheduler will truly schedule processes as sched_smt_power_savings should do. Signed-off-by: Youquan Song <youquan.song@...el.com> Tested-by: Anhua Xu <anhua.xu@...el.com> --- kernel/sched/fair.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index a4d2b7a..5be1d43 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3715,6 +3715,9 @@ unsigned long default_scale_smt_power(struct sched_domain *sd, int cpu) unsigned long weight = sd->span_weight; unsigned long smt_gain = sd->smt_gain; + if (sched_smt_power_savings) + return SCHED_POWER_SCALE; + smt_gain /= weight; return smt_gain; -- 1.6.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists