From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: tglx@linutronix.de, peterz@infradead.org,
paulmck@linux.vnet.ibm.com, rusty@rustcorp.com.au,
mingo@kernel.org, akpm@linux-foundation.org, namhyung@kernel.org,
vincent.guittot@linaro.org, tj@kernel.org, sbw@mit.edu,
amit.kucheria@linaro.org, rostedt@goodmis.org, rjw@sisk.pl,
wangyun@linux.vnet.ibm.com, xiaoguangrong@linux.vnet.ibm.com,
nikunj@linux.vnet.ibm.com, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 01/10] CPU hotplug: Provide APIs for "light" atomic readers to prevent CPU offline
Date: Thu, 06 Dec 2012 00:46:40 +0530 [thread overview]
Message-ID: <50BF9D98.6060609@linux.vnet.ibm.com> (raw)
In-Reply-To: <20121205190703.GA13795@redhat.com>
On 12/06/2012 12:37 AM, Oleg Nesterov wrote:
> I'll try to read this series later,
>
> one minor and almost offtopic nit.
>
> On 12/06, Srivatsa S. Bhat wrote:
>>
>> static int __ref take_cpu_down(void *_param)
>> {
>> struct take_cpu_down_param *param = _param;
>> + unsigned long flags;
>> int err;
>>
>> + /*
>> + * __cpu_disable() is the step where the CPU is removed from the
>> + * cpu_online_mask. Protect it with the light-lock held for write.
>> + */
>> + write_lock_irqsave(&light_hotplug_rwlock, flags);
>> +
>> /* Ensure this CPU doesn't handle any more interrupts. */
>> err = __cpu_disable();
>> - if (err < 0)
>> + if (err < 0) {
>> + write_unlock_irqrestore(&light_hotplug_rwlock, flags);
>> return err;
>> + }
>> +
>> + /*
>> + * We have successfully removed the CPU from the cpu_online_mask.
>> + * So release the light-lock, so that the light-weight atomic readers
>> + * (who care only about the cpu_online_mask updates, and not really
>> + * about the actual cpu-take-down operation) can continue.
>> + *
>> + * But don't enable interrupts yet, because we still have work left to
>> + * do, to actually bring the CPU down.
>> + */
>> + write_unlock(&light_hotplug_rwlock);
>>
>> cpu_notify(CPU_DYING | param->mod, param->hcpu);
>> +
>> + local_irq_restore(flags);
>> return 0;
>
> This is subjective, but imho _irqsave and the fat comment look confusing.
>
> Currently take_cpu_down() is always called with irqs disabled, so you
> do not need to play with interrupts.
>
> 10/10 does s/__stop_machine/stop_cpus/ and that patch could simply add
> local_irq_disable/enable into take_cpu_down().
>
Hmm, we could certainly do that, but somehow I felt it would be easier to
read if we tinker and fix up the take_cpu_down() logic at one place, as a
whole, instead of breaking up into pieces in different patches. And that
also makes the last patch look really cute: it just replaces stop_machine()
with stop_cpus(), as the changelog intended.
I'll see if doing like what you suggested improves the readability, and
if yes, I'll change it. Thank you!
Regards,
Srivatsa S. Bhat
next prev parent reply other threads:[~2012-12-05 19:18 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-05 18:42 [RFC PATCH v2 00/10][RESEND] CPU hotplug: stop_machine()-free CPU hotplug Srivatsa S. Bhat
2012-12-05 18:43 ` [RFC PATCH v2 01/10] CPU hotplug: Provide APIs for "light" atomic readers to prevent CPU offline Srivatsa S. Bhat
2012-12-05 18:47 ` Srivatsa S. Bhat
2012-12-05 18:51 ` Srivatsa S. Bhat
2012-12-05 18:53 ` Srivatsa S. Bhat
2012-12-05 18:56 ` Srivatsa S. Bhat
2012-12-05 18:59 ` Srivatsa S. Bhat
2012-12-05 20:14 ` Srivatsa S. Bhat
2012-12-06 16:18 ` Oleg Nesterov
2012-12-06 18:48 ` Srivatsa S. Bhat
2012-12-06 19:17 ` Srivatsa S. Bhat
2012-12-07 21:01 ` Oleg Nesterov
2012-12-06 19:28 ` Steven Rostedt
2012-12-06 19:36 ` Srivatsa S. Bhat
2012-12-06 22:02 ` Steven Rostedt
2012-12-07 17:33 ` Srivatsa S. Bhat
[not found] ` <20121207200014.GB13238@redhat.com>
2012-12-10 18:21 ` Oleg Nesterov
2012-12-10 19:07 ` Steven Rostedt
2012-12-07 19:56 ` Oleg Nesterov
2012-12-07 20:25 ` Srivatsa S. Bhat
2012-12-07 20:59 ` Oleg Nesterov
2012-12-05 19:07 ` Oleg Nesterov
2012-12-05 19:16 ` Srivatsa S. Bhat [this message]
2012-12-05 18:43 ` [RFC PATCH v2 02/10] CPU hotplug: Provide APIs for "full" " Srivatsa S. Bhat
2012-12-05 19:01 ` Srivatsa S. Bhat
2012-12-05 20:31 ` Srivatsa S. Bhat
2012-12-05 20:57 ` Tejun Heo
2012-12-06 4:31 ` Srivatsa S. Bhat
2012-12-05 18:43 ` [RFC PATCH v2 03/10] CPU hotplug: Convert preprocessor macros to static inline functions Srivatsa S. Bhat
2012-12-05 18:43 ` [RFC PATCH v2 04/10] smp, cpu hotplug: Fix smp_call_function_*() to prevent CPU offline properly Srivatsa S. Bhat
2012-12-05 18:43 ` [RFC PATCH v2 05/10] smp, cpu hotplug: Fix on_each_cpu_*() " Srivatsa S. Bhat
2012-12-05 18:44 ` [RFC PATCH v2 06/10] sched, cpu hotplug: Use stable online cpus in try_to_wake_up() & select_task_rq() Srivatsa S. Bhat
2012-12-05 18:44 ` [RFC PATCH v2 07/10] kick_process(), cpu-hotplug: Prevent offlining of target CPU properly Srivatsa S. Bhat
2012-12-05 18:44 ` [RFC PATCH v2 08/10] yield_to(), cpu-hotplug: Prevent offlining of other CPUs properly Srivatsa S. Bhat
2012-12-05 18:44 ` [RFC PATCH v2 09/10] kvm, vmx: Add full atomic synchronization with CPU Hotplug Srivatsa S. Bhat
2012-12-05 18:45 ` [RFC PATCH v2 10/10] cpu: No more __stop_machine() in _cpu_down() Srivatsa S. Bhat
2012-12-05 19:08 ` Oleg Nesterov
2012-12-05 19:12 ` Srivatsa S. Bhat
[not found] <20121205131038.17383.55472.stgit@srivatsabhat.in.ibm.com>
[not found] ` <20121205131136.17383.23318.stgit@srivatsabhat.in.ibm.com>
[not found] ` <20121205142316.GI3885@mtj.dyndns.org>
[not found] ` <20121205164640.GA7382@redhat.com>
[not found] ` <20121205165356.GL3885@mtj.dyndns.org>
2012-12-05 18:32 ` [RFC PATCH v2 01/10] CPU hotplug: Provide APIs for "light" atomic readers to prevent CPU offline Srivatsa S. Bhat
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=50BF9D98.6060609@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=amit.kucheria@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=nikunj@linux.vnet.ibm.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rjw@sisk.pl \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=sbw@mit.edu \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=wangyun@linux.vnet.ibm.com \
--cc=xiaoguangrong@linux.vnet.ibm.com \
/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).