From: Gautham R Shenoy <ego@in.ibm.com>
To: Nathan Lynch <ntl@pobox.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Rusty Russel <rusty@rustcorp.com.au>,
Dipankar Sarma <dipankar@in.ibm.com>,
Oleg Nesterov <oleg@tv-sign.ru>, Ingo Molnar <mingo@elte.hu>,
Paul E McKenney <paulmck@us.ibm.com>
Subject: Re: [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus
Date: Thu, 18 Oct 2007 14:29:59 +0530 [thread overview]
Message-ID: <20071018085959.GC15281@in.ibm.com> (raw)
In-Reply-To: <20071018082221.GE6773@localdomain>
On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote:
> Gautham R Shenoy wrote:
> > Hi Nathan,
> > > Hi Gautham-
> > >
> > > Gautham R Shenoy wrote:
> > > > Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
> > > > get_online_cpus and put_online_cpus instead as it highlights
> > > > the refcount semantics in these operations.
> > >
> > > Something other than "get_online_cpus", please? lock_cpu_hotplug()
> > > protects cpu_present_map as well as cpu_online_map. For example, some
> > > of the powerpc code modified in this patch is made a bit less clear
> > > because it is manipulating cpu_present_map, not cpu_online_map.
> >
> > A quick look at the code, and I am wondering why is lock_cpu_hotplug()
> > used there in the first place. It doesn't look like we require any
> > protection against cpus coming up/ going down in the code below,
> > since the cpu-hotplug operation doesn't affect the cpu_present_map.
>
> The locking is necessary. Changes to cpu_online_map and
> cpu_present_map must be serialized; otherwise you could end up trying
> to online a cpu as it is being removed (i.e. cleared from
> cpu_present_map). Online operations must check that a cpu is present
> before bringing it up (kernel/cpu.c):
Fair enough!
But we are not protecting the cpu_present_map here using
lock_cpu_hotplug(), now are we?
The lock_cpu_hotplug() here, ensures that no cpu-hotplug operations
occur in parallel with a processor add or a processor remove.
IOW, we're still ensuring that the cpu_online_map doesn't change
while we're changing the cpu_present_map. So I don't see why the name
get_online_cpus() should be a problem here. May be we could add a
comment as to why we don't want a cpu-hotplug operation to happen while
we're adding/removing a processor.
Unless of course, lock_cpu_hotplug() is also used to serialize
the add_processor and remove_processor operations. Is that the case
here ?
Thanks and Regards
gautham.
>
> /* Requires cpu_add_remove_lock to be held */
> static int __cpuinit _cpu_up(unsigned int cpu, int tasks_frozen)
> {
> int ret, nr_calls = 0;
> void *hcpu = (void *)(long)cpu;
> unsigned long mod = tasks_frozen ? CPU_TASKS_FROZEN : 0;
>
> if (cpu_online(cpu) || !cpu_present(cpu))
> return -EINVAL;
> ....
>
> > Can't we use another mutex here instead of the cpu_hotplug mutex here ?
>
> I guess so, but I don't really see the need...
>
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
next prev parent reply other threads:[~2007-10-18 9:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-16 10:33 [RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit Gautham R Shenoy
2007-10-16 10:34 ` [RFC PATCH 1/4] Refcount Based Cpu-Hotplug Implementation Gautham R Shenoy
2007-10-17 0:47 ` Rusty Russell
2007-10-17 5:37 ` Gautham R Shenoy
2007-10-17 6:29 ` Rusty Russell
2007-10-18 6:29 ` Gautham R Shenoy
2007-10-21 12:47 ` Oleg Nesterov
2007-10-17 10:53 ` Paul Jackson
2007-10-17 11:27 ` Paul Jackson
2007-10-17 11:50 ` Gautham R Shenoy
2007-10-17 12:04 ` Paul Jackson
2007-10-16 10:35 ` [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus Gautham R Shenoy
2007-10-17 16:13 ` Nathan Lynch
2007-10-18 7:57 ` Gautham R Shenoy
2007-10-18 8:22 ` Nathan Lynch
2007-10-18 8:59 ` Gautham R Shenoy [this message]
2007-10-18 17:30 ` Nathan Lynch
2007-10-19 5:04 ` Gautham R Shenoy
2007-10-22 0:43 ` Nathan Lynch
2007-10-22 4:51 ` Gautham R Shenoy
2007-10-16 10:36 ` [RFC PATCH 3/4] Replace per-subsystem mutexes with get_online_cpus Gautham R Shenoy
2007-10-21 11:39 ` Oleg Nesterov
2007-10-22 4:58 ` Gautham R Shenoy
2007-10-16 10:37 ` [RFC PATCH 4/4] Remove CPU_DEAD/CPU_UP_CANCELLED handling from workqueue.c Gautham R Shenoy
2007-10-17 11:57 ` Oleg Nesterov
2007-10-16 17:20 ` [RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit Linus Torvalds
2007-10-17 2:11 ` Dipankar Sarma
2007-10-17 2:23 ` Linus Torvalds
2007-10-17 4:17 ` Gautham R Shenoy
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=20071018085959.GC15281@in.ibm.com \
--to=ego@in.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=ntl@pobox.com \
--cc=oleg@tv-sign.ru \
--cc=paulmck@us.ibm.com \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@linux-foundation.org \
--cc=vatsa@in.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 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.