From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966752AbbBDPwl (ORCPT ); Wed, 4 Feb 2015 10:52:41 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:53282 "EHLO e39.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965319AbbBDPwj (ORCPT ); Wed, 4 Feb 2015 10:52:39 -0500 Date: Wed, 4 Feb 2015 07:46:13 -0800 From: "Paul E. McKenney" To: Russell King - ARM Linux Cc: Krzysztof Kozlowski , Fengguang Wu , LKP , linux-kernel@vger.kernel.org, Bartlomiej Zolnierkiewicz , linux-arm-kernel@lists.infradead.org, Arnd Bergmann , MarkRutland Subject: Re: [rcu] [ INFO: suspicious RCU usage. ] Message-ID: <20150204154613.GE5370@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150201025922.GA16820@wfg-t540p.sh.intel.com> <1422957702.17540.1.camel@AMDC1943> <20150203162704.GR19109@linux.vnet.ibm.com> <1423049947.19547.6.camel@AMDC1943> <20150204130018.GG8656@n2100.arm.linux.org.uk> <20150204131420.GC5370@linux.vnet.ibm.com> <1423059387.24415.2.camel@AMDC1943> <20150204151028.GD5370@linux.vnet.ibm.com> <20150204151624.GI8656@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150204151624.GI8656@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15020415-0033-0000-0000-0000038E94C4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 04, 2015 at 03:16:24PM +0000, Russell King - ARM Linux wrote: > On Wed, Feb 04, 2015 at 07:10:28AM -0800, Paul E. McKenney wrote: > > You know, this situation is giving me a bad case of nostalgia for the > > old Sequent Symmetry and NUMA-Q hardware. On those platforms, the > > outgoing CPU could turn itself off, and thus didn't need to tell some > > other CPU when it was ready to be turned off. Seems to me that this > > self-turn-off capability would be a great feature for future systems! > > Unfortunately, some briliant people decided that secure firmware on > their platforms (which is sometimes needed to turn the secondary CPUs > off) can only be called by CPU0... > > Other people decide that they can power down the secondary CPU when it > hits a WFI (wait for interrupt) instruction after arming that state > change, which is far saner - but we still need to know on the requesting > CPU when the dying CPU has completed the time-expensive parts of the > offlining process. I suppose that you could grant the outgoing CPU the ability to arm that state, but easy for me to say... Anyway, still looks like a pure polling loop is required, with short timed waits running on the surviving CPU. Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 From: paulmck@linux.vnet.ibm.com (Paul E. McKenney) Date: Wed, 4 Feb 2015 07:46:13 -0800 Subject: [rcu] [ INFO: suspicious RCU usage. ] In-Reply-To: <20150204151624.GI8656@n2100.arm.linux.org.uk> References: <20150201025922.GA16820@wfg-t540p.sh.intel.com> <1422957702.17540.1.camel@AMDC1943> <20150203162704.GR19109@linux.vnet.ibm.com> <1423049947.19547.6.camel@AMDC1943> <20150204130018.GG8656@n2100.arm.linux.org.uk> <20150204131420.GC5370@linux.vnet.ibm.com> <1423059387.24415.2.camel@AMDC1943> <20150204151028.GD5370@linux.vnet.ibm.com> <20150204151624.GI8656@n2100.arm.linux.org.uk> Message-ID: <20150204154613.GE5370@linux.vnet.ibm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Feb 04, 2015 at 03:16:24PM +0000, Russell King - ARM Linux wrote: > On Wed, Feb 04, 2015 at 07:10:28AM -0800, Paul E. McKenney wrote: > > You know, this situation is giving me a bad case of nostalgia for the > > old Sequent Symmetry and NUMA-Q hardware. On those platforms, the > > outgoing CPU could turn itself off, and thus didn't need to tell some > > other CPU when it was ready to be turned off. Seems to me that this > > self-turn-off capability would be a great feature for future systems! > > Unfortunately, some briliant people decided that secure firmware on > their platforms (which is sometimes needed to turn the secondary CPUs > off) can only be called by CPU0... > > Other people decide that they can power down the secondary CPU when it > hits a WFI (wait for interrupt) instruction after arming that state > change, which is far saner - but we still need to know on the requesting > CPU when the dying CPU has completed the time-expensive parts of the > offlining process. I suppose that you could grant the outgoing CPU the ability to arm that state, but easy for me to say... Anyway, still looks like a pure polling loop is required, with short timed waits running on the surviving CPU. Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7837838258032213428==" MIME-Version: 1.0 From: Paul E. McKenney To: lkp@lists.01.org Subject: Re: [rcu] [ INFO: suspicious RCU usage. ] Date: Wed, 04 Feb 2015 07:46:13 -0800 Message-ID: <20150204154613.GE5370@linux.vnet.ibm.com> In-Reply-To: <20150204151624.GI8656@n2100.arm.linux.org.uk> List-Id: --===============7837838258032213428== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Feb 04, 2015 at 03:16:24PM +0000, Russell King - ARM Linux wrote: > On Wed, Feb 04, 2015 at 07:10:28AM -0800, Paul E. McKenney wrote: > > You know, this situation is giving me a bad case of nostalgia for the > > old Sequent Symmetry and NUMA-Q hardware. On those platforms, the > > outgoing CPU could turn itself off, and thus didn't need to tell some > > other CPU when it was ready to be turned off. Seems to me that this > > self-turn-off capability would be a great feature for future systems! > = > Unfortunately, some briliant people decided that secure firmware on > their platforms (which is sometimes needed to turn the secondary CPUs > off) can only be called by CPU0... > = > Other people decide that they can power down the secondary CPU when it > hits a WFI (wait for interrupt) instruction after arming that state > change, which is far saner - but we still need to know on the requesting > CPU when the dying CPU has completed the time-expensive parts of the > offlining process. I suppose that you could grant the outgoing CPU the ability to arm that state, but easy for me to say... Anyway, still looks like a pure polling loop is required, with short timed waits running on the surviving CPU. Thanx, Paul --===============7837838258032213428==--