From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>, Tejun Heo <tj@kernel.org>,
akpm@linux-foundation.org, fweisbec@gmail.com,
paulmck@linux.vnet.ibm.com, tglx@linutronix.de, mingo@kernel.org,
rusty@rustcorp.com.au, hch@infradead.org, mgorman@suse.de,
riel@redhat.com, bp@suse.de, rostedt@goodmis.org,
mgalbraith@suse.de, ego@linux.vnet.ibm.com, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 UPDATEDv3 3/3] CPU hotplug, smp: Flush any pending IPI callbacks before CPU offline
Date: Tue, 20 May 2014 16:12:37 +0530 [thread overview]
Message-ID: <537B319D.30603@linux.vnet.ibm.com> (raw)
In-Reply-To: <537B309C.7000100@linux.vnet.ibm.com>
On 05/20/2014 04:08 PM, Srivatsa S. Bhat wrote:
> On 05/20/2014 04:01 PM, Srivatsa S. Bhat wrote:
>> On 05/20/2014 03:55 PM, Peter Zijlstra wrote:
>>> On Tue, May 20, 2014 at 03:39:59PM +0530, Srivatsa S. Bhat wrote:
>>>>> The multi_cpu_stop() path isn't exclusive to hotplug, so your changelog
>>>>> is wrong or the patch is.
>>>>>
>>>>
>>>> Yes, I know that multi_cpu_stop() isn't exclusive to hotplug. That's why
>>>> I have explicitly referred to CPU hotplug in the comment as well as the
>>>> changelog.
>>>>
>>>> But I totally agree that code-wise this is not the best way to do it since
>>>> this affects (although harmlessly) usecases other than hotplug as well.
>>>>
>>>> Do you have any other suggestions?
>>>
>>> How about making a kernel/smp.c hotplug notifier and stuffing it in the
>>> CPU_DYING list? That's typically after we've already torn down the
>>> interrupts for that cpu, so no chance of any new ones coming in.
>>>
>>> Or is that too late?
>>>
>>
>> No, that should work just fine. Thank you for the suggestion! I'll give
>> it a shot.
>>
>
> The only problem will be that CPU_DYING notifiers are run after marking
> the CPU offline, and hence the warning will trigger. We can avoid that by
> defining a __generic_smp_call_function_single_interrupt() that doesn't
> check for cpu_online(smp_processor_id) and call this function from the
> hotplug notifier.
>
>
(And that's probably something to fix while cleaning up hotplug later:
Why should we mark the CPU offline _before_ running CPU_DYING? It makes
more sense to mark it offline _after_ running CPU_DYING notifiers. I'll
audit that path as well and see what I can find).
Regards,
Srivatsa S. Bhat
next prev parent reply other threads:[~2014-05-20 10:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 19:12 [PATCH v5 0/3] CPU hotplug: Fix the long-standing "IPI to offline CPU" issue Srivatsa S. Bhat
2014-05-15 19:13 ` [PATCH v5 1/3] smp: Print more useful debug info upon receiving IPI on an offline CPU Srivatsa S. Bhat
2014-05-15 19:19 ` Joe Perches
2014-05-15 19:34 ` Srivatsa S. Bhat
2014-05-15 19:43 ` Joe Perches
2014-05-15 19:51 ` [PATCH v5 UPDATED " Srivatsa S. Bhat
2014-05-15 19:13 ` [PATCH v5 2/3] CPU hotplug, stop-machine: Plug race-window that leads to "IPI-to-offline-CPU" Srivatsa S. Bhat
2014-05-15 19:17 ` Tejun Heo
2014-05-15 19:18 ` Srivatsa S. Bhat
2014-05-15 19:14 ` [PATCH v5 3/3] CPU hotplug, smp: Flush any pending IPI callbacks before CPU offline Srivatsa S. Bhat
2014-05-15 19:19 ` Tejun Heo
2014-05-15 19:26 ` Srivatsa S. Bhat
2014-05-15 19:36 ` Paul E. McKenney
2014-05-15 19:43 ` [PATCH v5 UPDATED " Srivatsa S. Bhat
2014-05-15 19:45 ` Tejun Heo
2014-05-19 12:19 ` [PATCH v5 UPDATEDv2 " Srivatsa S. Bhat
2014-05-19 16:18 ` Oleg Nesterov
2014-05-19 19:49 ` Srivatsa S. Bhat
2014-05-19 20:22 ` [PATCH v5 UPDATEDv3 " Srivatsa S. Bhat
2014-05-20 9:42 ` Peter Zijlstra
2014-05-20 10:09 ` Srivatsa S. Bhat
2014-05-20 10:25 ` Peter Zijlstra
2014-05-20 10:31 ` Srivatsa S. Bhat
2014-05-20 10:38 ` Srivatsa S. Bhat
2014-05-20 10:42 ` Srivatsa S. Bhat [this message]
2014-05-15 19:44 ` [PATCH v5 " Tejun Heo
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=537B319D.30603@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--cc=ego@linux.vnet.ibm.com \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgalbraith@suse.de \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=tj@kernel.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;
as well as URLs for NNTP newsgroup(s).