Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762080AbXJXSW6 (ORCPT ); Wed, 24 Oct 2007 14:22:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756385AbXJXSWt (ORCPT ); Wed, 24 Oct 2007 14:22:49 -0400 Received: from E23SMTP04.au.ibm.com ([202.81.18.173]:33975 "EHLO e23smtp04.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756241AbXJXSWr (ORCPT ); Wed, 24 Oct 2007 14:22:47 -0400 Date: Wed, 24 Oct 2007 23:52:10 +0530 From: Gautham R Shenoy To: Oleg Nesterov Cc: Christoph Lameter , Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Rusty Russel , Srivatsa Vaddagiri , Dipankar Sarma , Ingo Molnar , Paul E McKenney , Richard Gooch , Tigran Aivazian , Shoahua Li , Ralf Baechle , Heiko Carstens , Nathan Lynch , David Miller , Paul Jackson , Josh Triplett , Pekka Enberg , Akinobu Mita Subject: Re: [RFC PATCH 0/5] Refcount based Cpu Hotplug. V2 Message-ID: <20071024182210.GA10884@in.ibm.com> Reply-To: ego@in.ibm.com References: <20071024052931.GA22722@in.ibm.com> <20071024180034.GB8663@in.ibm.com> <20071024181754.GC345@tv-sign.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071024181754.GC345@tv-sign.ru> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1439 Lines: 42 On Wed, Oct 24, 2007 at 10:17:54PM +0400, Oleg Nesterov wrote: > On 10/24, Gautham R Shenoy wrote: > > > > On Wed, Oct 24, 2007 at 10:04:41AM -0700, Christoph Lameter wrote: > > > On Wed, 24 Oct 2007, Gautham R Shenoy wrote: > > > > > > > This is the version 2 of the refcount based cpu-hotplug "locking" > > > > implementation. > > > > > > Uggh. This introduces a global lock that has to be taken always when > > > scanning over cpus? > > > > Well, no! we take the global lock only while bumping up the refcount. > > We don't hold the lock while scanning over the cpus. And this is > > definitely an improvement over the lock_cpu_hotplug() global mutex > > we have now. > > Just to be sure I didn't miss something... preempt_disable() still works, > yes? Yes it does. But it doesn't prevent onlining of new cpus. I am checking if __cpu_up() can also be called safely using stop_machine_run() so that we can use preempt_disable() for safe atomic access of the cpu_online_map. > > Oleg. > Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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/