Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753464Ab2FRCwM (ORCPT ); Sun, 17 Jun 2012 22:52:12 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:49419 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752854Ab2FRCwL (ORCPT ); Sun, 17 Jun 2012 22:52:11 -0400 Date: Mon, 18 Jun 2012 10:51:59 +0800 From: Yong Zhang To: "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, ralf@linux-mips.org, sshtylyov@mvista.com, david.daney@cavium.com, nikunj@linux.vnet.ibm.com, axboe@kernel.dk, mingo@kernel.org, tglx@linutronix.de, peterz@infradead.org, akpm@linux-foundation.org, srivatsa.bhat@linux.vnet.ibm.com, Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH 09/10] POWERPC: smp: remove call to ipi_call_lock()/ipi_call_unlock() Message-ID: <20120618025159.GA24420@zhy> Reply-To: Yong Zhang References: <1338275765-3217-1-git-send-email-yong.zhang0@gmail.com> <1338275765-3217-10-git-send-email-yong.zhang0@gmail.com> <20120616163219.GI2420@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120616163219.GI2420@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2941 Lines: 83 On Sat, Jun 16, 2012 at 09:32:19AM -0700, Paul E. McKenney wrote: > On Tue, May 29, 2012 at 03:16:04PM +0800, Yong Zhang wrote: > > From: Yong Zhang > > > > 1) call_function.lock used in smp_call_function_many() is just to protect > > call_function.queue and &data->refs, cpu_online_mask is outside of the > > lock. And it's not necessary to protect cpu_online_mask, > > because data->cpumask is pre-calculate and even if a cpu is brougt up > > when calling arch_send_call_function_ipi_mask(), it's harmless because > > validation test in generic_smp_call_function_interrupt() will take care > > of it. > > > > 2) For cpu down issue, stop_machine() will guarantee that no concurrent > > smp_call_fuction() is processing. > > However, there is an effort to get rid of stop_machine() from the > CPU-down path... So something else will be needed. Yeah. So Thomas changed the commit log like below: [ ipi_call_lock/unlock() lock resp. unlock call_function.lock. This lock protects only the call_function data structure itself, but it's completely unrelated to cpu_online_mask. The mask to which the IPIs are sent is calculated before call_function.lock is taken in smp_call_function_many(), so the locking around set_cpu_online() is pointless and can be removed. [ tglx: Massaged changelog ] ] in tip/smp/hotplug. Thanks, Yong > > Thanx, Paul > > > Signed-off-by: Yong Zhang > > Cc: Benjamin Herrenschmidt > > Cc: Paul Mackerras > > Cc: linuxppc-dev@lists.ozlabs.org > > --- > > arch/powerpc/kernel/smp.c | 2 -- > > 1 files changed, 0 insertions(+), 2 deletions(-) > > > > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c > > index e4cb343..e1417c4 100644 > > --- a/arch/powerpc/kernel/smp.c > > +++ b/arch/powerpc/kernel/smp.c > > @@ -571,7 +571,6 @@ void __devinit start_secondary(void *unused) > > if (system_state == SYSTEM_RUNNING) > > vdso_data->processorCount++; > > #endif > > - ipi_call_lock(); > > notify_cpu_starting(cpu); > > set_cpu_online(cpu, true); > > /* Update sibling maps */ > > @@ -601,7 +600,6 @@ void __devinit start_secondary(void *unused) > > of_node_put(np); > > } > > of_node_put(l2_cache); > > - ipi_call_unlock(); > > > > local_irq_enable(); > > > > -- > > 1.7.5.4 > > > > -- > 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/ -- Only stand for myself -- 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/