Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751863AbZDMRe2 (ORCPT ); Mon, 13 Apr 2009 13:34:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750747AbZDMReT (ORCPT ); Mon, 13 Apr 2009 13:34:19 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:56275 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750713AbZDMReS (ORCPT ); Mon, 13 Apr 2009 13:34:18 -0400 Date: Mon, 13 Apr 2009 10:27:49 -0700 From: Andrew Morton To: Ingo Molnar Cc: Linus Torvalds , Valdis.Kletnieks@vt.edu, Mike Travis , Linux Kernel Mailing List , mm-commits@vger.kernel.org, Rusty Russell , Dave Jones , Len Brown Subject: Re: mmotm 2009-04-10-02-21 uploaded - forkbombed by work_for_cpu Message-Id: <20090413102749.4ca3a217.akpm@linux-foundation.org> In-Reply-To: <20090413171853.GA4601@elte.hu> References: <200904100922.n3A9MOIV013828@imap1.linux-foundation.org> <4609.1239456126@turing-police.cc.vt.edu> <20090413171853.GA4601@elte.hu> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5055 Lines: 164 On Mon, 13 Apr 2009 19:18:53 +0200 Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > So I do think Andrew's commit is broken and we should think about > > it a bit more, but I also think that Valdis' problem comes from > > acpi-cpufreq just being damn stupid. Doing a > > smp_call_function_single() to read two MSR's is going to be a > > _lot_ more efficient than doing that crazy work_on_cpu() for that. > > > > So the _real_ problem came through the commits like > > > > cpufreq: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write > > cpumask: use work_on_cpu in acpi-cpufreq.c for read_measured_perf_ctrs > > > > that were meant to reduce stack usage with big cpu masks. And > > sure, the _old_ way of doing it was also stupid (it rescheduled > > the process to the other CPU by using cpus_allowed()). > > > > Mike, Ingo? > > I think Andrew has a stack of fixes queued up, one of which should > solve this problem too - which Mike tested - as the commit from > Andrew has caused another regression as well. > > There's no sha1 - the patch is in this thread on lkml: > > sysbench(oltp)+mysql 10% regression with 2.6.30-rc1 > > | From: Andrew Morton > | > | Atttempting to rid us of the problematic work_on_cpu(). Just use > | smp_call_fuction_single() here. > | > | This repairs a 10% sysbench(oltp)+mysql regression which Mike > | reported, > Yup. It's presently in Len's hands. And Rusty's. Vladis, perhaps you can verify? From: Andrew Morton Atttempting to rid us of the problematic work_on_cpu(). Just use smp_call_fuction_single() here. This repairs a 10% sysbench(oltp)+mysql regression which Mike reported, due to commit 6b44003e5ca66a3fffeb5bc90f40ada2c4340896 Author: Andrew Morton Date: Thu Apr 9 09:50:37 2009 -0600 work_on_cpu(): rewrite it to create a kernel thread on demand It seems that the kernel calls these acpi-cpufreq functions at a quite high frequency. Cc: Rusty Russell Cc: Ingo Molnar Cc: Venkatesh Pallipadi Cc: Len Brown Cc: Zhao Yakui Cc: Dave Jones Cc: Thomas Gleixner Tested-by: Mike Galbraith Cc: "Zhang, Yanmin" Signed-off-by: Andrew Morton --- arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 25 ++++++++----------- 1 file changed, 11 insertions(+), 14 deletions(-) diff -puN arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c~arch-x86-kernel-cpu-cpufreq-acpi-cpufreqc-avoid-using-work_on_cpu arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c --- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c~arch-x86-kernel-cpu-cpufreq-acpi-cpufreqc-avoid-using-work_on_cpu +++ a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c @@ -153,7 +153,8 @@ struct drv_cmd { u32 val; }; -static long do_drv_read(void *_cmd) +/* Called via smp_call_function_single(), on the target CPU */ +static void do_drv_read(void *_cmd) { struct drv_cmd *cmd = _cmd; u32 h; @@ -170,10 +171,10 @@ static long do_drv_read(void *_cmd) default: break; } - return 0; } -static long do_drv_write(void *_cmd) +/* Called via smp_call_function_single(), on the target CPU */ +static void do_drv_write(void *_cmd) { struct drv_cmd *cmd = _cmd; u32 lo, hi; @@ -192,23 +193,21 @@ static long do_drv_write(void *_cmd) default: break; } - return 0; } static void drv_read(struct drv_cmd *cmd) { cmd->val = 0; - work_on_cpu(cpumask_any(cmd->mask), do_drv_read, cmd); + smp_call_function_single(cpumask_any(cmd->mask), do_drv_read, cmd, 1); } static void drv_write(struct drv_cmd *cmd) { - unsigned int i; + unsigned int cpu; - for_each_cpu(i, cmd->mask) { - work_on_cpu(i, do_drv_write, cmd); - } + for_each_cpu(cpu, cmd->mask) + smp_call_function_single(cpu, do_drv_write, cmd, 1); } static u32 get_cur_val(const struct cpumask *mask) @@ -252,15 +251,13 @@ struct perf_pair { } aperf, mperf; }; - -static long read_measured_perf_ctrs(void *_cur) +/* Called via smp_call_function_single(), on the target CPU */ +static void read_measured_perf_ctrs(void *_cur) { struct perf_pair *cur = _cur; rdmsr(MSR_IA32_APERF, cur->aperf.split.lo, cur->aperf.split.hi); rdmsr(MSR_IA32_MPERF, cur->mperf.split.lo, cur->mperf.split.hi); - - return 0; } /* @@ -283,7 +280,7 @@ static unsigned int get_measured_perf(st unsigned int perf_percent; unsigned int retval; - if (!work_on_cpu(cpu, read_measured_perf_ctrs, &readin)) + if (smp_call_function_single(cpu, read_measured_perf_ctrs, &cur, 1)) return 0; cur.aperf.whole = readin.aperf.whole - _ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/