From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> To: paulus@samba.org, oleg@redhat.com, rusty@rustcorp.com.au, peterz@infradead.org, tglx@linutronix.de, akpm@linux-foundation.org Cc: paulmck@linux.vnet.ibm.com, tj@kernel.org, walken@google.com, ego@linux.vnet.ibm.com, linux@arm.linux.org.uk, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, srivatsa.bhat@linux.vnet.ibm.com, Rob Landley <rob@landley.net>, Ingo Molnar <mingo@kernel.org>, linux-doc@vger.kernel.org"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> Subject: [PATCH v2 03/52] Doc/cpu-hotplug: Specify race-free way to register CPU hotplug callbacks Date: Fri, 14 Feb 2014 13:19:35 +0530 [thread overview] Message-ID: <20140214074934.22701.75638.stgit@srivatsabhat.in.ibm.com> (raw) In-Reply-To: <20140214074750.22701.47330.stgit@srivatsabhat.in.ibm.com> Recommend the usage of the new CPU hotplug callback registration APIs (__register_cpu_notifier() etc), when subsystems need to also perform initialization for already online CPUs. Provide examples of correct and race-free ways of achieving this, and point out the kinds of code that are error-prone. Cc: Rob Landley <rob@landley.net> Cc: Ingo Molnar <mingo@kernel.org> Cc: linux-doc@vger.kernel.org Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> --- Documentation/cpu-hotplug.txt | 45 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index be675d2..a0b005d 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -312,12 +312,57 @@ things will happen if a notifier in path sent a BAD notify code. Q: I don't see my action being called for all CPUs already up and running? A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined. If you need to perform some action for each cpu already in the system, then + do this: for_each_online_cpu(i) { foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i); foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i); } + However, if you want to register a hotplug callback, as well as perform + some initialization for CPUs that are already online, then do this: + + Version 1: (Correct) + --------- + + cpu_notifier_register_begin(); + + for_each_online_cpu(i) { + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_UP_PREPARE, i); + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_ONLINE, i); + } + + /* Note the use of the double underscored version of the API */ + __register_cpu_notifier(&foobar_cpu_notifier); + + cpu_notifier_register_done(); + + Note that the following code is *NOT* the right way to achieve this, + because it is prone to an ABBA deadlock between the cpu_add_remove_lock + and the cpu_hotplug.lock. + + Version 2: (Wrong!) + --------- + + get_online_cpus(); + + for_each_online_cpu(i) { + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_UP_PREPARE, i); + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_ONLINE, i); + } + + register_cpu_notifier(&foobar_cpu_notifier); + + put_online_cpus(); + + So always use the first version shown above when you want to register + callbacks as well as initialize the already online CPUs. + + Q: If i would like to develop cpu hotplug support for a new architecture, what do i need at a minimum? A: The following are what is required for CPU hotplug infrastructure to work
WARNING: multiple messages have this Message-ID (diff)
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> To: paulus@samba.org, oleg@redhat.com, mingo@kernel.org, rusty@rustcorp.com.au, peterz@infradead.org, tglx@linutronix.de, akpm@linux-foundation.org Cc: paulmck@linux.vnet.ibm.com, tj@kernel.org, walken@google.com, ego@linux.vnet.ibm.com, linux@arm.linux.org.uk, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, srivatsa.bhat@linux.vnet.ibm.com, Rob Landley <rob@landley.net>, linux-doc@vger.kernel.org"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> Subject: [PATCH v2 03/52] Doc/cpu-hotplug: Specify race-free way to register CPU hotplug callbacks Date: Fri, 14 Feb 2014 13:19:35 +0530 [thread overview] Message-ID: <20140214074934.22701.75638.stgit@srivatsabhat.in.ibm.com> (raw) Message-ID: <20140214074935.V6gI9mBRi7sVMfDD0QznuDMr-kXK4dVPd29S6l4GIwE@z> (raw) In-Reply-To: <20140214074750.22701.47330.stgit@srivatsabhat.in.ibm.com> Recommend the usage of the new CPU hotplug callback registration APIs (__register_cpu_notifier() etc), when subsystems need to also perform initialization for already online CPUs. Provide examples of correct and race-free ways of achieving this, and point out the kinds of code that are error-prone. Cc: Rob Landley <rob@landley.net> Cc: Ingo Molnar <mingo@kernel.org> Cc: linux-doc@vger.kernel.org Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> --- Documentation/cpu-hotplug.txt | 45 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index be675d2..a0b005d 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -312,12 +312,57 @@ things will happen if a notifier in path sent a BAD notify code. Q: I don't see my action being called for all CPUs already up and running? A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined. If you need to perform some action for each cpu already in the system, then + do this: for_each_online_cpu(i) { foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i); foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i); } + However, if you want to register a hotplug callback, as well as perform + some initialization for CPUs that are already online, then do this: + + Version 1: (Correct) + --------- + + cpu_notifier_register_begin(); + + for_each_online_cpu(i) { + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_UP_PREPARE, i); + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_ONLINE, i); + } + + /* Note the use of the double underscored version of the API */ + __register_cpu_notifier(&foobar_cpu_notifier); + + cpu_notifier_register_done(); + + Note that the following code is *NOT* the right way to achieve this, + because it is prone to an ABBA deadlock between the cpu_add_remove_lock + and the cpu_hotplug.lock. + + Version 2: (Wrong!) + --------- + + get_online_cpus(); + + for_each_online_cpu(i) { + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_UP_PREPARE, i); + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_ONLINE, i); + } + + register_cpu_notifier(&foobar_cpu_notifier); + + put_online_cpus(); + + So always use the first version shown above when you want to register + callbacks as well as initialize the already online CPUs. + + Q: If i would like to develop cpu hotplug support for a new architecture, what do i need at a minimum? A: The following are what is required for CPU hotplug infrastructure to work
next prev parent reply other threads:[~2014-02-14 7:55 UTC|newest] Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-02-14 7:49 [PATCH v2 00/52] CPU hotplug: Fix issues with callback registration Srivatsa S. Bhat 2014-02-14 7:49 ` [PATCH v2 01/52] CPU hotplug: Add lockdep annotations to get/put_online_cpus() Srivatsa S. Bhat 2014-02-14 7:49 ` Srivatsa S. Bhat 2014-02-14 7:49 ` [PATCH v2 02/52] CPU hotplug: Provide lockless versions of callback registration functions Srivatsa S. Bhat 2014-02-14 7:49 ` Srivatsa S. Bhat 2014-02-17 13:26 ` Gautham R Shenoy 2014-02-19 21:34 ` Toshi Kani 2014-02-14 7:49 ` Srivatsa S. Bhat [this message] 2014-02-14 7:49 ` [PATCH v2 03/52] Doc/cpu-hotplug: Specify race-free way to register CPU hotplug callbacks Srivatsa S. Bhat 2014-02-14 7:49 ` [PATCH v2 04/52] CPU hotplug, perf: Fix CPU hotplug callback registration Srivatsa S. Bhat 2014-02-14 7:49 ` Srivatsa S. Bhat 2014-02-14 7:50 ` [PATCH v2 05/52] ia64, salinfo: Fix " Srivatsa S. Bhat 2014-02-14 7:50 ` Srivatsa S. Bhat 2014-02-14 7:50 ` [PATCH v2 06/52] ia64, palinfo: Fix CPU " Srivatsa S. Bhat 2014-02-14 7:50 ` Srivatsa S. Bhat 2014-02-14 7:50 ` [PATCH v2 07/52] ia64, topology: " Srivatsa S. Bhat 2014-02-14 7:50 ` Srivatsa S. Bhat 2014-02-14 7:50 ` [PATCH v2 08/52] ia64, err-inject: " Srivatsa S. Bhat 2014-02-14 7:50 ` Srivatsa S. Bhat 2014-02-14 7:51 ` [PATCH v2 09/52] arm, hw-breakpoint: " Srivatsa S. Bhat 2014-02-14 7:51 ` Srivatsa S. Bhat 2014-02-14 7:51 ` [PATCH v2 10/52] arm, kvm: " Srivatsa S. Bhat 2014-02-14 7:51 ` Srivatsa S. Bhat 2014-02-14 10:29 ` Paolo Bonzini 2014-02-14 10:29 ` Paolo Bonzini 2014-02-14 7:51 ` [PATCH v2 11/52] s390, cacheinfo: " Srivatsa S. Bhat 2014-02-14 7:51 ` Srivatsa S. Bhat 2014-02-14 7:51 ` [PATCH v2 12/52] s390, smp: " Srivatsa S. Bhat 2014-02-14 7:51 ` Srivatsa S. Bhat 2014-02-14 7:52 ` [PATCH v2 13/52] sparc, sysfs: " Srivatsa S. Bhat 2014-02-14 7:52 ` Srivatsa S. Bhat 2014-02-14 18:30 ` David Miller 2014-02-14 7:52 ` [PATCH v2 14/52] powerpc, " Srivatsa S. Bhat 2014-02-14 7:52 ` Srivatsa S. Bhat 2014-03-07 2:57 ` Benjamin Herrenschmidt 2014-03-07 2:57 ` Benjamin Herrenschmidt 2014-03-07 6:21 ` Gautham R Shenoy 2014-02-14 7:52 ` [PATCH v2 15/52] x86, msr: " Srivatsa S. Bhat 2014-02-14 7:52 ` Srivatsa S. Bhat 2014-02-14 7:52 ` [PATCH v2 16/52] x86, cpuid: " Srivatsa S. Bhat 2014-02-14 7:52 ` Srivatsa S. Bhat 2014-02-14 7:52 ` [PATCH v2 17/52] x86, vsyscall: " Srivatsa S. Bhat 2014-02-14 7:52 ` Srivatsa S. Bhat 2014-02-14 7:53 ` [PATCH v2 18/52] x86, intel, uncore: " Srivatsa S. Bhat 2014-02-14 7:53 ` Srivatsa S. Bhat 2014-02-14 7:53 ` [PATCH v2 19/52] x86, mce: " Srivatsa S. Bhat 2014-02-14 7:53 ` Srivatsa S. Bhat 2014-02-14 7:53 ` [PATCH v2 20/52] x86, therm_throt.c: " Srivatsa S. Bhat 2014-02-14 7:53 ` Srivatsa S. Bhat 2014-02-14 7:53 ` [PATCH v2 21/52] x86, therm_throt.c: Remove unused therm_cpu_lock Srivatsa S. Bhat 2014-02-14 7:53 ` Srivatsa S. Bhat 2014-02-14 7:54 ` [PATCH v2 22/52] x86, amd, ibs: Fix CPU hotplug callback registration Srivatsa S. Bhat 2014-02-14 7:54 ` Srivatsa S. Bhat 2014-02-14 7:54 ` [PATCH v2 23/52] x86, intel, cacheinfo: " Srivatsa S. Bhat 2014-02-14 7:54 ` Srivatsa S. Bhat 2014-02-14 7:54 ` [PATCH v2 24/52] x86, intel, rapl: " Srivatsa S. Bhat 2014-02-14 7:54 ` Srivatsa S. Bhat 2014-02-14 7:54 ` [PATCH v2 25/52] x86, amd, uncore: " Srivatsa S. Bhat 2014-02-14 7:54 ` Srivatsa S. Bhat 2014-02-14 7:55 ` [PATCH v2 26/52] x86, hpet: " Srivatsa S. Bhat 2014-02-14 7:55 ` Srivatsa S. Bhat 2014-02-14 7:55 ` [PATCH v2 27/52] x86, pci, amd-bus: " Srivatsa S. Bhat 2014-02-14 7:55 ` Srivatsa S. Bhat 2014-02-14 17:35 ` Bjorn Helgaas 2014-02-14 18:03 ` Srivatsa S. Bhat 2014-02-14 18:03 ` Srivatsa S. Bhat 2014-02-14 7:55 ` [PATCH v2 28/52] x86, oprofile, nmi: " Srivatsa S. Bhat 2014-02-14 7:55 ` Srivatsa S. Bhat 2014-02-14 7:55 ` [PATCH v2 29/52] x86, kvm: " Srivatsa S. Bhat 2014-02-14 7:55 ` Srivatsa S. Bhat 2014-02-14 10:29 ` Paolo Bonzini 2014-02-14 7:55 ` [PATCH v2 30/52] arm64, hw_breakpoint.c: " Srivatsa S. Bhat 2014-02-14 7:55 ` Srivatsa S. Bhat 2014-02-14 7:56 ` [PATCH v2 31/52] arm64, debug-monitors: " Srivatsa S. Bhat 2014-02-14 7:56 ` Srivatsa S. Bhat 2014-02-14 7:56 ` [PATCH v2 32/52] powercap, intel-rapl: " Srivatsa S. Bhat 2014-02-14 7:56 ` Srivatsa S. Bhat 2014-02-14 7:56 ` [PATCH v2 33/52] scsi, bnx2i: " Srivatsa S. Bhat 2014-02-14 7:56 ` Srivatsa S. Bhat 2014-02-14 7:56 ` [PATCH v2 34/52] scsi, bnx2fc: " Srivatsa S. Bhat 2014-02-14 7:56 ` Srivatsa S. Bhat 2014-02-14 7:57 ` [PATCH v2 35/52] scsi, fcoe: " Srivatsa S. Bhat 2014-02-14 7:57 ` Srivatsa S. Bhat 2014-02-14 7:57 ` [PATCH v2 36/52] zsmalloc: " Srivatsa S. Bhat 2014-02-14 7:57 ` Srivatsa S. Bhat 2014-02-14 7:57 ` [PATCH v2 37/52] acpi-cpufreq: " Srivatsa S. Bhat 2014-02-14 7:57 ` Srivatsa S. Bhat 2014-02-14 7:57 ` [PATCH v2 38/52] drivers/base/topology.c: " Srivatsa S. Bhat 2014-02-14 7:57 ` Srivatsa S. Bhat 2014-02-15 19:38 ` Greg Kroah-Hartman 2014-02-14 7:58 ` [PATCH v2 39/52] clocksource, dummy-timer: " Srivatsa S. Bhat 2014-02-14 7:58 ` Srivatsa S. Bhat 2014-02-14 7:58 ` [PATCH v2 40/52] intel-idle: " Srivatsa S. Bhat 2014-02-14 7:58 ` Srivatsa S. Bhat 2014-02-14 7:58 ` [PATCH v2 41/52] oprofile, nmi-timer: " Srivatsa S. Bhat 2014-02-14 7:58 ` Srivatsa S. Bhat 2014-02-14 7:58 ` [PATCH v2 42/52] octeon, watchdog: " Srivatsa S. Bhat 2014-02-14 7:58 ` Srivatsa S. Bhat 2014-02-14 7:58 ` [PATCH v2 43/52] thermal, x86-pkg-temp: " Srivatsa S. Bhat 2014-02-14 7:58 ` Srivatsa S. Bhat 2014-02-14 7:59 ` [PATCH v2 44/52] hwmon, coretemp: " Srivatsa S. Bhat 2014-02-14 7:59 ` Srivatsa S. Bhat 2014-02-14 7:59 ` [PATCH v2 45/52] hwmon, via-cputemp: " Srivatsa S. Bhat 2014-02-14 7:59 ` Srivatsa S. Bhat 2014-02-14 7:59 ` [PATCH v2 46/52] xen, balloon: " Srivatsa S. Bhat 2014-02-14 7:59 ` Srivatsa S. Bhat 2014-02-14 16:49 ` Boris Ostrovsky 2014-02-14 16:49 ` Boris Ostrovsky 2014-02-14 16:50 ` Srivatsa S. Bhat 2014-02-15 16:51 ` [UPDATED][PATCH " Srivatsa S. Bhat 2014-02-17 14:50 ` Boris Ostrovsky 2014-02-14 7:59 ` [PATCH v2 47/52] trace, ring-buffer: " Srivatsa S. Bhat 2014-02-14 7:59 ` Srivatsa S. Bhat 2014-02-14 8:00 ` [PATCH v2 48/52] profile: " Srivatsa S. Bhat 2014-02-14 8:00 ` Srivatsa S. Bhat 2014-02-14 8:00 ` [PATCH v2 49/52] mm, vmstat: " Srivatsa S. Bhat 2014-02-14 8:00 ` Srivatsa S. Bhat 2014-02-14 14:26 ` Rik van Riel 2014-02-14 14:26 ` Rik van Riel 2014-02-14 8:00 ` [PATCH v2 50/52] mm, zswap: " Srivatsa S. Bhat 2014-02-14 8:00 ` Srivatsa S. Bhat 2014-02-14 8:00 ` [PATCH v2 51/52] net/core/flow.c: " Srivatsa S. Bhat 2014-02-14 8:00 ` Srivatsa S. Bhat 2014-02-14 18:31 ` David Miller 2014-02-14 8:00 ` [PATCH v2 52/52] net/iucv/iucv.c: " Srivatsa S. Bhat 2014-02-14 8:00 ` Srivatsa S. Bhat 2014-02-14 18:31 ` David Miller 2014-02-18 8:56 ` [PATCH v2 00/52] CPU hotplug: Fix issues with " Srivatsa S. Bhat 2014-02-18 8:56 ` 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=20140214074934.22701.75638.stgit@srivatsabhat.in.ibm.com \ --to=srivatsa.bhat@linux.vnet.ibm.com \ --cc=akpm@linux-foundation.org \ --cc=ego@linux.vnet.ibm.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --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=rjw@rjwysocki.net \ --cc=rob@landley.net \ --cc=rusty@rustcorp.com.au \ --cc=tglx@linutronix.de \ --cc=tj@kernel.org \ --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: linkBe 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).