From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org,
dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com,
fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com,
linux-api@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH v2 tip/core/rcu 01/22] smpboot: Add common code for notification from dying CPU
Date: Tue, 17 Mar 2015 10:32:58 -0700 [thread overview]
Message-ID: <20150317173258.GP3589@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150317165621.GF24151@twins.programming.kicks-ass.net>
On Tue, Mar 17, 2015 at 05:56:21PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 17, 2015 at 03:08:46PM +0100, Peter Zijlstra wrote:
> > On Tue, Mar 17, 2015 at 04:36:48AM -0700, Paul E. McKenney wrote:
> > > On Tue, Mar 17, 2015 at 09:18:07AM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 16, 2015 at 11:37:45AM -0700, Paul E. McKenney wrote:
> > > > > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > > > >
> > > > > RCU ignores offlined CPUs, so they cannot safely run RCU read-side code.
> > > > > (They -can- use SRCU, but not RCU.) This means that any use of RCU
> > > > > during or after the call to arch_cpu_idle_dead(). Unfortunately,
> > > > > commit 2ed53c0d6cc99 added a complete() call, which will contain RCU
> > > > > read-side critical sections if there is a task waiting to be awakened.
> > > >
> > > > Got a little more detail there?
> > >
> > > Quite possibly. But exactly what sort of detail are you looking for?
> >
> > What exact RCU usage you ran into that was problematic. It seems to
> > imply that calling complete() -- from a dead cpu -- which ends up in
> > try_to_wake_up() was the problem?
>
> Hmm, I'm thinking its select_task_rq_*(). And yes, 'fixing' this in the
> wake-up path will penalize everybody for the benefit of the very rare
> case someone is doing a hotplug.
>
> So yeah, maybe this is the best solution.. Ulgy though :/
Ugly indeed! I end up doing a polling loop for the generic code. For the
first round, I updated only architectures that were calling complete().
If that goes well, I will probably update some of the other architecture
as a code-consolidation measure. Some architectures have special hardware
and firmware hooks, for example, s390 uses a special instruction to do
the wakeup directly. Those will of course continue doing their own thing.
The ARM guys are trying to do something specific to their hardware, but
I have not heard from them lately. I should ping them...
Thanx, Paul
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
laijs-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org,
dipankar-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org,
josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org,
dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
bobby.prani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2 tip/core/rcu 01/22] smpboot: Add common code for notification from dying CPU
Date: Tue, 17 Mar 2015 10:32:58 -0700 [thread overview]
Message-ID: <20150317173258.GP3589@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150317165621.GF24151-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
On Tue, Mar 17, 2015 at 05:56:21PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 17, 2015 at 03:08:46PM +0100, Peter Zijlstra wrote:
> > On Tue, Mar 17, 2015 at 04:36:48AM -0700, Paul E. McKenney wrote:
> > > On Tue, Mar 17, 2015 at 09:18:07AM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 16, 2015 at 11:37:45AM -0700, Paul E. McKenney wrote:
> > > > > From: "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> > > > >
> > > > > RCU ignores offlined CPUs, so they cannot safely run RCU read-side code.
> > > > > (They -can- use SRCU, but not RCU.) This means that any use of RCU
> > > > > during or after the call to arch_cpu_idle_dead(). Unfortunately,
> > > > > commit 2ed53c0d6cc99 added a complete() call, which will contain RCU
> > > > > read-side critical sections if there is a task waiting to be awakened.
> > > >
> > > > Got a little more detail there?
> > >
> > > Quite possibly. But exactly what sort of detail are you looking for?
> >
> > What exact RCU usage you ran into that was problematic. It seems to
> > imply that calling complete() -- from a dead cpu -- which ends up in
> > try_to_wake_up() was the problem?
>
> Hmm, I'm thinking its select_task_rq_*(). And yes, 'fixing' this in the
> wake-up path will penalize everybody for the benefit of the very rare
> case someone is doing a hotplug.
>
> So yeah, maybe this is the best solution.. Ulgy though :/
Ugly indeed! I end up doing a polling loop for the generic code. For the
first round, I updated only architectures that were calling complete().
If that goes well, I will probably update some of the other architecture
as a code-consolidation measure. Some architectures have special hardware
and firmware hooks, for example, s390 uses a special instruction to do
the wakeup directly. Those will of course continue doing their own thing.
The ARM guys are trying to do something specific to their hardware, but
I have not heard from them lately. I should ping them...
Thanx, Paul
next prev parent reply other threads:[~2015-03-17 17:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 18:37 [PATCH v2 tip/core/rcu 0/22] CPU hotplug updates for v4.1 Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 01/22] smpboot: Add common code for notification from dying CPU Paul E. McKenney
2015-03-16 18:37 ` Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 02/22] x86: Use common outgoing-CPU-notification code Paul E. McKenney
2015-03-16 18:37 ` Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 03/22] blackfin: " Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 04/22] metag: " Paul E. McKenney
2015-03-16 18:37 ` Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 05/22] rcu: Consolidate offline-CPU callback initialization Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 06/22] rcu: Put all orphan-callback-related code under same comment Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 07/22] rcu: Simplify sync_rcu_preempt_exp_init() Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 08/22] rcu: Eliminate empty HOTPLUG_CPU ifdef Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 09/22] rcu: Detect stalls caused by failure to propagate up rcu_node tree Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 10/22] rcu: Provide diagnostic option to slow down grace-period initialization Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 11/22] rcutorture: Enable slow grace-period initializations Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 12/22] rcu: Remove event tracing from rcu_cpu_notify(), used by offline CPUs Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 13/22] rcu: Rework preemptible expedited bitmask handling Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 14/22] rcu: Move rcu_report_unblock_qs_rnp() to common code Paul E. McKenney
2015-03-16 18:37 ` [PATCH v2 tip/core/rcu 15/22] rcu: Process offlining and onlining only at grace-period start Paul E. McKenney
2015-03-16 18:38 ` [PATCH v2 tip/core/rcu 16/22] rcu: Eliminate ->onoff_mutex from rcu_node structure Paul E. McKenney
2015-03-16 18:38 ` [PATCH v2 tip/core/rcu 17/22] cpu: Make CPU-offline idle-loop transition point more precise Paul E. McKenney
2015-03-16 18:38 ` [PATCH v2 tip/core/rcu 18/22] rcu: Handle outgoing CPUs on exit from idle loop Paul E. McKenney
2015-03-16 18:38 ` [PATCH v2 tip/core/rcu 19/22] rcutorture: Default to grace-period-initialization delays Paul E. McKenney
2015-03-16 18:38 ` [PATCH v2 tip/core/rcu 20/22] rcu: Add diagnostics to grace-period cleanup Paul E. McKenney
2015-03-16 18:38 ` [PATCH v2 tip/core/rcu 21/22] rcu: Yet another fix for preemption and CPU hotplug Paul E. McKenney
2015-03-16 18:38 ` [PATCH v2 tip/core/rcu 22/22] rcu: Associate quiescent-state reports with grace period Paul E. McKenney
2015-03-17 8:18 ` [PATCH v2 tip/core/rcu 01/22] smpboot: Add common code for notification from dying CPU Peter Zijlstra
2015-03-17 8:18 ` Peter Zijlstra
2015-03-17 11:36 ` Paul E. McKenney
2015-03-17 11:36 ` Paul E. McKenney
2015-03-17 14:08 ` Peter Zijlstra
2015-03-17 16:34 ` Paul E. McKenney
2015-03-17 16:56 ` Peter Zijlstra
2015-03-17 17:32 ` Paul E. McKenney [this message]
2015-03-17 17:32 ` 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=20150317173258.GP3589@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bobby.prani@gmail.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=dvhart@linux.intel.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.