From: James Hogan <james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
To: paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@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,
peterz-wEGCiKHe2LqWVfeAwA7xHQ@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-metag-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH tip/core/rcu 04/20] metag: Use common outgoing-CPU-notification code
Date: Wed, 11 Mar 2015 11:03:18 +0000 [thread overview]
Message-ID: <550020F6.6020105@imgtec.com> (raw)
In-Reply-To: <20150310165935.GR5708-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4149 bytes --]
On 10/03/15 16:59, Paul E. McKenney wrote:
> On Tue, Mar 10, 2015 at 03:30:42PM +0000, James Hogan wrote:
>> Hi Paul,
>>
>> On 03/03/15 17:42, Paul E. McKenney wrote:
>>> From: "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>>
>>> This commit removes the open-coded CPU-offline notification with new
>>> common code. This change avoids calling scheduler code using RCU from
>>> an offline CPU that RCU is ignoring. This commit is compatible with
>>> the existing code in not checking for timeout during a prior offline
>>> for a given CPU.
>>>
>>> Signed-off-by: Paul E. McKenney <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>> Cc: James Hogan <james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
>>> Cc: <linux-metag-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>
>> I gave this a try via linux-next, but unfortunately it causes the
>> following warning every time a CPU goes down:
>> META213-Thread0 DSP [LogF] CPU1: unable to kill
>
> That is certainly not what I had in mind, thank you for finding this!
>
>> If I add printks, I see that the state on entry to both cpu_wait_death
>> and cpu_report_death is already CPU_POST_DEAD, suggesting that it hasn't
>> changed from its initial value.
>>
>> Should arches other than x86 now be calling cpu_set_state_online()? The
>> patchlet below seems to resolve it for Meta (not sure if that is the
>> best place in the startup sequence to do it, perhaps it doesn't matter).
>>
>> diff --git a/arch/metag/kernel/smp.c b/arch/metag/kernel/smp.c
>> index ac3a199e33e7..430e379ec71f 100644
>> --- a/arch/metag/kernel/smp.c
>> +++ b/arch/metag/kernel/smp.c
>> @@ -383,6 +383,7 @@ asmlinkage void secondary_start_kernel(void)
>> * OK, now it's safe to let the boot CPU continue
>> */
>> set_cpu_online(cpu, true);
>> + cpu_set_state_online(cpu);
>> complete(&cpu_running);
>>
>> /*
>>
>> Looking at the comment before cpu_set_state_online:
>>> /*
>>> * Mark the specified CPU online.
>>> *
>>> * Note that it is permissible to omit this call entirely, as is
>>> * done in architectures that do no CPU-hotplug error checking.
>>> */
>>
>> Which suggests it wasn't wrong to omit it before your patches came
>> along.
>
> And that suggestion is quite correct. The idea was indeed to accommodate
> architectures that do not do error checking.
>
> Does the following patch (on top of current -next) remove the need for
> your addition of cpu_set_state_online() above?
Don't forget the "oldstate == ", otherwise it'll work for the wrong
reason :-/
Checking for CPU_POST_DEAD does seem to fix the immediate problem,
however this still leaves open the possibility of a single timeout
propagating to all further offlines after CPU_DEAD_FROZEN gets set. I've
confirmed that by adding a delay loop only on the second
cpu_report_death() call, and sure enough the 2nd and further offlines
all fail even though the CPU stops immediately after the 2nd one.
If this check is primarily so that CPU_DEAD_FROZEN is set if
cpu_wait_death timed out, would it be better to instead check explicitly
for CPU_BROKEN?
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 18688e0b0422..c697f73d82d6 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -460,7 +460,7 @@ bool cpu_report_death(void)
do {
oldstate = atomic_read(&per_cpu(cpu_hotplug_state, cpu));
- if (oldstate == CPU_ONLINE)
+ if (oldstate != CPU_BROKEN)
newstate = CPU_DEAD;
else
newstate = CPU_DEAD_FROZEN;
Cheers
James
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> diff --git a/kernel/smpboot.c b/kernel/smpboot.c
> index 18688e0b0422..80400e019c86 100644
> --- a/kernel/smpboot.c
> +++ b/kernel/smpboot.c
> @@ -460,7 +460,7 @@ bool cpu_report_death(void)
>
> do {
> oldstate = atomic_read(&per_cpu(cpu_hotplug_state, cpu));
> - if (oldstate == CPU_ONLINE)
> + if (oldstate == CPU_ONLINE || CPU_POST_DEAD)
> newstate = CPU_DEAD;
> else
> newstate = CPU_DEAD_FROZEN;
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-03-11 11:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150303174144.GA13139@linux.vnet.ibm.com>
[not found] ` <1425404595-17816-1-git-send-email-paulmck@linux.vnet.ibm.com>
2015-03-03 17:42 ` [PATCH tip/core/rcu 04/20] metag: Use common outgoing-CPU-notification code Paul E. McKenney
[not found] ` <1425404595-17816-4-git-send-email-paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-03-10 15:30 ` James Hogan
2015-03-10 16:59 ` Paul E. McKenney
[not found] ` <20150310165935.GR5708-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-03-11 11:03 ` James Hogan [this message]
[not found] ` <550020F6.6020105-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2015-03-11 18:58 ` 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=550020F6.6020105@imgtec.com \
--to=james.hogan-1axoqhu6uovqt0dzr+alfa@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=bobby.prani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=dipankar-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org \
--cc=dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org \
--cc=laijs-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-metag-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org \
--cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox