Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755290Ab2FFInV (ORCPT ); Wed, 6 Jun 2012 04:43:21 -0400 Received: from merlin.infradead.org ([205.233.59.134]:48505 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752555Ab2FFInO convert rfc822-to-8bit (ORCPT ); Wed, 6 Jun 2012 04:43:14 -0400 Message-ID: <1338972175.2749.78.camel@twins> Subject: Re: [PATCH 0/6] x86/cpu hotplug: Wake up offline CPU via mwait or nmi From: Peter Zijlstra To: paulmck@linux.vnet.ibm.com Cc: Thomas Gleixner , "Luck, Tony" , "Yu, Fenghua" , Rusty Russell , Ingo Molnar , H Peter Anvin , "Siddha, Suresh B" , "Mallick, Asit K" , Arjan Dan De Ven , linux-kernel , x86 , linux-pm , "Srivatsa S. Bhat" Date: Wed, 06 Jun 2012 10:42:55 +0200 In-Reply-To: <20120605221240.GW2388@linux.vnet.ibm.com> References: <3E5A0FA7E9CA944F9D5414FEC6C7122007727023@ORSMSX105.amr.corp.intel.com> <1338912565.2749.9.camel@twins> <3E5A0FA7E9CA944F9D5414FEC6C7122007728081@ORSMSX105.amr.corp.intel.com> <1338913190.2749.10.camel@twins> <3908561D78D1C84285E8C5FCA982C28F19300965@ORSMSX104.amr.corp.intel.com> <1338918625.2749.29.camel@twins> <1338925756.2749.36.camel@twins> <1338931856.2749.57.camel@twins> <20120605221240.GW2388@linux.vnet.ibm.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Evolution 3.2.2- Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1322 Lines: 27 On Tue, 2012-06-05 at 15:12 -0700, Paul E. McKenney wrote: > > RCU has similar nasties. > > I am working to rid RCU of this sort of thing. I have rcu_barrier() so > that it avoids messing with CPUs that don't have callbacks, which will > be almost all of the idle CPUs, especially for CONFIG_RCU_FAST_NO_HZ=y. > I believe that I have also removed all of RCU's dependencies on CPU > hotplug's using kstopmachine, though Murphy would say otherwise. > > I still need to fix up synchronize_sched_expedited(), but that is on > the list. I considered getting rid of this one, but I am probably going > to have to make synchronize_sched() map to it during boot time to keep > the boot-speed demons satisfied. Not the point really. Its perfectly fine for applications in an 'isolated' set to use system calls, hence they get to participate in RCU state. I don't think the isolation means userspace while(1) applications is interesting. Sure, some people do this, and we should dtrt for them, but the far more interesting case is 'regular' applications that do use system calls. -- 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/