linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Toshi Kani <toshi.kani@hp.com>
Cc: paulus@samba.org, oleg@redhat.com, rusty@rustcorp.com.au,
	peterz@infradead.org, tglx@linutronix.de,
	akpm@linux-foundation.org, mingo@kernel.org,
	paulmck@linux.vnet.ibm.com, tj@kernel.org, walken@google.com,
	ego@linux.vnet.ibm.com, linux@arm.linux.org.uk,
	linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH 01/51] CPU hotplug: Provide lockless versions of callback registration functions
Date: Tue, 11 Feb 2014 14:57:45 +0530	[thread overview]
Message-ID: <52F9ED11.5010800@linux.vnet.ibm.com> (raw)
In-Reply-To: <1392081980.5612.123.camel@misato.fc.hp.com>

On 02/11/2014 06:56 AM, Toshi Kani wrote:
> On Thu, 2014-02-06 at 03:34 +0530, Srivatsa S. Bhat wrote:
>  :
[...]
>>
>> Also, since cpu_maps_update_begin/done() is like a super-set of
>> get/put_online_cpus(), the former naturally protects the critical sections
>> from concurrent hotplug operations.
> 
> get/put_online_cpus() is a reader-lock and concurrent executions are
> allowed among the readers.  They won't be serialized until a cpu
> online/offline operation begins.  By replacing this lock with
> cpu_maps_update_begin/done(), we now serialize all readers.  Isn't that
> too restrictive?

That's an excellent line of thought! It doesn't really hurt at the moment
because the for_each_online_cpu() kind of loop that the initcalls of various
subsystems run (before registering the notifier) are really tiny (typically
the loop runs for just 1 cpu, the boot-cpu). In other words, this change
represents a tiny increase in the critical section size; so its effect
shouldn't be noticeable. (Note that in the old model, register_cpu_notifier()
already takes the cpu_add_remove_lock, so they will be serialized at that
point, and this is necessary).

However, going forward, when we start using more aggressive CPU onlining
techniques during boot (such as parallel CPU hotplug), the issue you pointed
out can become a real bottleneck, since for_each_online_cpu() can become
quite a large loop, and hence explicit (and unnecessary) mutual exclusion
will start hurting.
 
>  Can we fix the issue with CPU_POST_DEAD and continue
> to use get_online_cpus()?
> 

We don't want to get rid of CPU_POST_DEAD, so unfortunately we can't continue
to use get_online_cpus(). However, I am thinking of introducing a Reader-Writer
semaphore for this purpose, so that the registration routines can run in
parallel most of the time. (Basically, the rw-semaphore is like
get/put_online_cpus(), except that it protects the full hotplug critical section,
including the CPU_POST_DEAD stage.)

The usage would be like this:

	cpu_notifier_register_begin(); //does down_read(&cpu_hotplug_rwsem);

	for_each_online_cpu(cpu)
		init_cpu(cpu);

	/* Takes cpu_add_remove_lock mutex */
	register_cpu_notifier(&foobar_cpu_notifier);

	cpu_notifier_register_end(); //does up_read(&cpu_hotplug_rwsem);

An untested RFC patch is shown below. With this, the task performing CPU hotplug
will take the locks in this order:

	down_write(&cpu_hotplug_rwsem);
	mutex_lock(&cpu_add_remove_lock);

	mutex_lock(&cpu_hotplug.lock);

	//Perform CPU hotplug

	mutex_unlock(&cpu_hotplug.lock);

	mutex_unlock(&cpu_add_remove_lock);
	up_write(&cpu_hotplug_rwsem);


The APIs register/unregister_cpu_notifiers will take only the
cpu_add_remove_lock mutex during callback registration.


-----------------------------------------------------------------------------

diff --git a/kernel/cpu.c b/kernel/cpu.c
index deff2e6..8054e6f 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -23,6 +23,19 @@
 #include "smpboot.h"
 
 #ifdef CONFIG_SMP
+
+static DECLARE_RWSEM(cpu_hotplug_rwsem);
+
+void cpu_notifier_register_begin(void)
+{
+	down_read(&cpu_hotplug_rwsem);
+}
+
+void cpu_notifier_register_end(void)
+{
+	up_read(&cpu_hotplug_rwsem);
+}
+
 /* Serializes the updates to cpu_online_mask, cpu_present_mask */
 static DEFINE_MUTEX(cpu_add_remove_lock);
 
@@ -32,12 +45,14 @@ static DEFINE_MUTEX(cpu_add_remove_lock);
  */
 void cpu_maps_update_begin(void)
 {
+	down_write(&cpu_hotplug_rwsem);
 	mutex_lock(&cpu_add_remove_lock);
 }
 
 void cpu_maps_update_done(void)
 {
 	mutex_unlock(&cpu_add_remove_lock);
+	up_write(&cpu_hotplug_rwsem);
 }
 
 static RAW_NOTIFIER_HEAD(cpu_chain);
@@ -160,9 +175,10 @@ void cpu_hotplug_enable(void)
 int __ref register_cpu_notifier(struct notifier_block *nb)
 {
 	int ret;
-	cpu_maps_update_begin();
+
+	mutex_lock(&cpu_add_remove_lock);
 	ret = raw_notifier_chain_register(&cpu_chain, nb);
-	cpu_maps_update_done();
+	mutex_unlock(&cpu_add_remove_lock);
 	return ret;
 }
 
@@ -192,9 +208,9 @@ EXPORT_SYMBOL(register_cpu_notifier);
 
 void __ref unregister_cpu_notifier(struct notifier_block *nb)
 {
-	cpu_maps_update_begin();
+	mutex_lock(&cpu_add_remove_lock);
 	raw_notifier_chain_unregister(&cpu_chain, nb);
-	cpu_maps_update_done();
+	mutex_unlock(&cpu_add_remove_lock);
 }
 EXPORT_SYMBOL(unregister_cpu_notifier);
 

Regards,
Srivatsa S. Bhat


  reply	other threads:[~2014-02-11  9:33 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-05 22:04 [PATCH 00/51] CPU hotplug: Fix issues with callback registration Srivatsa S. Bhat
2014-02-05 22:04 ` [PATCH 01/51] CPU hotplug: Provide lockless versions of callback registration functions Srivatsa S. Bhat
2014-02-06 18:41   ` Oleg Nesterov
2014-02-07 19:11     ` Gautham R Shenoy
2014-02-10  9:15       ` Srivatsa S. Bhat
2014-02-10 10:51         ` Gautham R Shenoy
2014-02-10 11:11           ` Srivatsa S. Bhat
2014-02-10 12:05             ` Gautham R Shenoy
2014-02-10 13:28               ` Srivatsa S. Bhat
2014-02-10 13:30           ` Srivatsa S. Bhat
2014-02-10 15:30           ` Oleg Nesterov
2014-02-10 17:27           ` Balbir Singh
2014-02-11  1:26   ` Toshi Kani
2014-02-11  9:27     ` Srivatsa S. Bhat [this message]
2014-02-11 16:33       ` Toshi Kani
2014-02-11 17:18         ` Gautham R Shenoy
2014-02-11 17:35           ` Toshi Kani
2014-02-11 19:20             ` Srivatsa S. Bhat
2014-02-11 20:51               ` Toshi Kani
2014-02-12  6:18                 ` Srivatsa S. Bhat
2014-02-13 10:56                   ` Srivatsa S. Bhat
2014-02-13 20:53                     ` Toshi Kani
2014-02-11 17:15       ` Oleg Nesterov
2014-02-11 19:08         ` Srivatsa S. Bhat
2014-02-13 17:44           ` Oleg Nesterov
2014-02-13 17:54             ` Srivatsa S. Bhat
2014-02-13 11:06     ` Gautham R Shenoy
2014-02-05 22:04 ` [PATCH 02/51] Doc/cpu-hotplug: Specify race-free way to register CPU hotplug callbacks Srivatsa S. Bhat
2014-02-05 22:05 ` [PATCH 03/51] CPU hotplug, perf: Fix CPU hotplug callback registration Srivatsa S. Bhat
2014-02-05 22:05 ` [PATCH 04/51] ia64, salinfo: Fix " Srivatsa S. Bhat
2014-02-05 22:05 ` [PATCH 05/51] ia64, palinfo: Fix CPU " Srivatsa S. Bhat
2014-02-05 22:05 ` [PATCH 06/51] ia64, topology: " Srivatsa S. Bhat
2014-02-05 22:05 ` [PATCH 07/51] ia64, err-inject: " Srivatsa S. Bhat
2014-02-05 22:06 ` [PATCH 08/51] arm, hw-breakpoint: " Srivatsa S. Bhat
2014-02-06 10:57   ` Will Deacon
2014-02-06 11:25     ` Srivatsa S. Bhat
2014-02-06 11:39       ` Will Deacon
2014-02-06 11:38         ` Srivatsa S. Bhat
2014-02-05 22:06 ` [PATCH 09/51] arm, kvm: " Srivatsa S. Bhat
2014-02-05 22:06 ` [PATCH 10/51] s390, cacheinfo: " Srivatsa S. Bhat
2014-02-05 22:06 ` [PATCH 11/51] s390, smp: " Srivatsa S. Bhat
2014-02-05 22:06 ` [PATCH 12/51] sparc, sysfs: " Srivatsa S. Bhat
2014-02-05 22:06 ` [PATCH 13/51] powerpc, " Srivatsa S. Bhat
2014-02-14  6:47   ` Madhavan Srinivasan
2014-02-05 22:07 ` [PATCH 14/51] x86, msr: " Srivatsa S. Bhat
2014-02-05 22:07 ` [PATCH 15/51] x86, cpuid: " Srivatsa S. Bhat
2014-02-05 22:07 ` [PATCH 16/51] x86, vsyscall: " Srivatsa S. Bhat
2014-02-10 18:50   ` Gautham R Shenoy
2014-02-11  6:58     ` Srivatsa S. Bhat
2014-02-05 22:07 ` [PATCH 17/51] x86, intel, uncore: " Srivatsa S. Bhat
2014-02-05 22:07 ` [PATCH 18/51] x86, mce: " Srivatsa S. Bhat
2014-02-05 22:08 ` [PATCH 19/51] x86, therm_throt.c: " Srivatsa S. Bhat
2014-02-10 15:53   ` Oleg Nesterov
2014-02-10 17:29     ` Srivatsa S. Bhat
2014-02-10 18:04       ` Srivatsa S. Bhat
2014-02-05 22:08 ` [PATCH 20/51] x86, amd, ibs: " Srivatsa S. Bhat
2014-02-05 22:08 ` [PATCH 21/51] x86, intel, cacheinfo: " Srivatsa S. Bhat
2014-02-05 22:08 ` [PATCH 22/51] x86, intel, rapl: " Srivatsa S. Bhat
2014-02-05 22:08 ` [PATCH 23/51] x86, amd, uncore: " Srivatsa S. Bhat
2014-02-05 22:09 ` [PATCH 24/51] x86, hpet: " Srivatsa S. Bhat
2014-02-10 18:58   ` Gautham R Shenoy
2014-02-11  6:59     ` Srivatsa S. Bhat
2014-02-05 22:09 ` [PATCH 25/51] x86, pci, amd-bus: " Srivatsa S. Bhat
2014-02-05 22:09 ` [PATCH 26/51] x86, oprofile, nmi: " Srivatsa S. Bhat
2014-02-10 19:07   ` Gautham R Shenoy
2014-02-10 19:27     ` Gautham R Shenoy
2014-02-11  7:01       ` Srivatsa S. Bhat
2014-02-05 22:09 ` [PATCH 27/51] x86, kvm: " Srivatsa S. Bhat
2014-02-05 22:09 ` [PATCH 28/51] arm64, hw_breakpoint.c: " Srivatsa S. Bhat
2014-02-06 11:41   ` Will Deacon
2014-02-05 22:09 ` [PATCH 29/51] arm64, debug-monitors: " Srivatsa S. Bhat
2014-02-06 11:41   ` Will Deacon
2014-02-05 22:10 ` [PATCH 30/51] powercap, intel-rapl: " Srivatsa S. Bhat
2014-02-05 22:10 ` [PATCH 31/51] scsi, bnx2i: " Srivatsa S. Bhat
2014-02-05 22:10 ` [PATCH 32/51] scsi, bnx2fc: " Srivatsa S. Bhat
2014-02-05 22:10 ` [PATCH 33/51] scsi, fcoe: " Srivatsa S. Bhat
2014-02-05 22:10 ` [PATCH 34/51] zsmalloc: " Srivatsa S. Bhat
2014-02-05 22:10 ` [PATCH 35/51] acpi-cpufreq: " Srivatsa S. Bhat
2014-02-06 12:43   ` Rafael J. Wysocki
2014-02-06 16:05     ` Srivatsa S. Bhat
2014-02-07  4:09   ` Viresh Kumar
2014-02-05 22:11 ` [PATCH 36/51] drivers/base/topology.c: " Srivatsa S. Bhat
2014-02-05 22:11 ` [PATCH 37/51] clocksource, dummy-timer: " Srivatsa S. Bhat
2014-02-05 22:11 ` [PATCH 38/51] intel-idle: " Srivatsa S. Bhat
2014-02-06 12:43   ` Rafael J. Wysocki
2014-02-06 16:04     ` Srivatsa S. Bhat
2014-02-05 22:11 ` [PATCH 39/51] oprofile, nmi-timer: " Srivatsa S. Bhat
2014-02-05 22:11 ` [PATCH 40/51] octeon, watchdog: " Srivatsa S. Bhat
2014-02-05 22:11 ` [PATCH 41/51] thermal, x86-pkg-temp: " Srivatsa S. Bhat
2014-02-05 22:12 ` [PATCH 42/51] hwmon, coretemp: " Srivatsa S. Bhat
2014-02-06  0:44   ` Guenter Roeck
2014-02-06  1:25     ` Guenter Roeck
2014-02-06 10:03       ` Srivatsa S. Bhat
2014-02-05 22:12 ` [PATCH 43/51] hwmon, via-cputemp: " Srivatsa S. Bhat
2014-02-06  0:44   ` Guenter Roeck
2014-02-06  1:26     ` Guenter Roeck
2014-02-05 22:12 ` [PATCH 44/51] xen, balloon: " Srivatsa S. Bhat
2014-02-05 22:12 ` [PATCH 45/51] md, raid5: " Srivatsa S. Bhat
2014-02-06  1:11   ` NeilBrown
2014-02-06 10:05     ` Srivatsa S. Bhat
2014-02-06 18:43       ` Oleg Nesterov
2014-02-05 22:12 ` [PATCH 46/51] trace, ring-buffer: " Srivatsa S. Bhat
2014-02-05 23:41   ` Steven Rostedt
2014-02-05 22:13 ` [PATCH 47/51] profile: " Srivatsa S. Bhat
2014-02-05 22:13 ` [PATCH 48/51] mm, vmstat: " Srivatsa S. Bhat
2014-02-06 15:35   ` Christoph Lameter
2014-02-07  2:52   ` Yasuaki Ishimatsu
2014-02-05 22:13 ` [PATCH 49/51] mm, zswap: " Srivatsa S. Bhat
2014-02-05 22:13 ` [PATCH 50/51] net/core/flow.c: " Srivatsa S. Bhat
2014-02-07  4:39   ` David Miller
2014-02-07  5:19     ` David Miller
2014-02-05 22:13 ` [PATCH 51/51] net/iucv/iucv.c: " Srivatsa S. Bhat
2014-02-07  4:39   ` David Miller
2014-02-07  5:19     ` David Miller
2014-02-06  9:38 ` [PATCH 00/51] CPU hotplug: Fix issues with " Gautham R Shenoy
2014-02-06 11:04   ` Srivatsa S. Bhat
2014-02-06 11:08     ` Srivatsa S. Bhat
2014-02-06 12:14     ` Gautham R Shenoy
2014-02-06 16:09       ` 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=52F9ED11.5010800@linux.vnet.ibm.com \
    --to=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ego@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=toshi.kani@hp.com \
    --cc=walken@google.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).