All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
To: lkp@lists.01.org
Subject: Re: [rcu] [ INFO: suspicious RCU usage. ]
Date: Wed, 04 Feb 2015 07:46:13 -0800	[thread overview]
Message-ID: <20150204154613.GE5370@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150204151624.GI8656@n2100.arm.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

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


WARNING: multiple messages have this Message-ID (diff)
From: paulmck@linux.vnet.ibm.com (Paul E. McKenney)
To: linux-arm-kernel@lists.infradead.org
Subject: [rcu] [ INFO: suspicious RCU usage. ]
Date: Wed, 4 Feb 2015 07:46:13 -0800	[thread overview]
Message-ID: <20150204154613.GE5370@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150204151624.GI8656@n2100.arm.linux.org.uk>

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

WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>,
	linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	Arnd Bergmann <arnd@arndb.de>, MarkRutland <mark.rutland@arm.com>
Subject: Re: [rcu] [ INFO: suspicious RCU usage. ]
Date: Wed, 4 Feb 2015 07:46:13 -0800	[thread overview]
Message-ID: <20150204154613.GE5370@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150204151624.GI8656@n2100.arm.linux.org.uk>

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


  reply	other threads:[~2015-02-04 15:46 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-01  2:59 [rcu] [ INFO: suspicious RCU usage. ] Fengguang Wu
2015-02-01  2:59 ` Fengguang Wu
2015-02-03 10:01 ` Krzysztof Kozlowski
2015-02-03 10:01   ` Krzysztof Kozlowski
2015-02-03 16:27   ` Paul E. McKenney
2015-02-03 16:27     ` Paul E. McKenney
2015-02-04 11:39     ` Krzysztof Kozlowski
2015-02-04 11:39       ` Krzysztof Kozlowski
2015-02-04 11:39       ` Krzysztof Kozlowski
2015-02-04 13:00       ` Russell King - ARM Linux
2015-02-04 13:00         ` Russell King - ARM Linux
2015-02-04 13:00         ` Russell King - ARM Linux
2015-02-04 13:14         ` Paul E. McKenney
2015-02-04 13:14           ` Paul E. McKenney
2015-02-04 13:14           ` Paul E. McKenney
2015-02-04 14:16           ` Krzysztof Kozlowski
2015-02-04 14:16             ` Krzysztof Kozlowski
2015-02-04 14:16             ` Krzysztof Kozlowski
2015-02-04 15:10             ` Paul E. McKenney
2015-02-04 15:10               ` Paul E. McKenney
2015-02-04 15:10               ` Paul E. McKenney
2015-02-04 15:16               ` Russell King - ARM Linux
2015-02-04 15:16                 ` Russell King - ARM Linux
2015-02-04 15:16                 ` Russell King - ARM Linux
2015-02-04 15:46                 ` Paul E. McKenney [this message]
2015-02-04 15:46                   ` Paul E. McKenney
2015-02-04 15:46                   ` Paul E. McKenney
2015-02-04 15:22               ` Krzysztof Kozlowski
2015-02-04 15:22                 ` Krzysztof Kozlowski
2015-02-04 15:22                 ` Krzysztof Kozlowski
2015-02-04 15:56                 ` Paul E. McKenney
2015-02-04 15:56                   ` Paul E. McKenney
2015-02-04 15:56                   ` Paul E. McKenney
2015-02-04 16:10                   ` Krzysztof Kozlowski
2015-02-04 16:10                     ` Krzysztof Kozlowski
2015-02-04 16:10                     ` Krzysztof Kozlowski
2015-02-04 16:28                     ` Paul E. McKenney
2015-02-04 16:28                       ` Paul E. McKenney
2015-02-04 16:28                       ` Paul E. McKenney
2015-02-04 16:43                       ` Krzysztof Kozlowski
2015-02-04 16:43                         ` Krzysztof Kozlowski
2015-02-04 16:43                         ` Krzysztof Kozlowski
2015-02-04 13:13       ` Paul E. McKenney
2015-02-04 13:13         ` Paul E. McKenney
2015-02-04 13:13         ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150204154613.GE5370@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=lkp@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.