From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:40:38
Hi,
This patchset removes CPU hotplug's dependence on stop_machine() from the CPU
offline path and provides an alternative (set of APIs) to preempt_disable() to
prevent CPUs from going offline, which can be invoked from atomic context.
The motivation behind the removal of stop_machine() is to avoid its ill-effects
and thus improve the design of CPU hotplug. (More description regarding this
is available in the patches).
All the users of preempt_disable()/local_irq_disable() who used to use it to
prevent CPU offline, have been converted to the new primitives introduced in the
patchset. Also, the CPU_DYING notifiers have been audited to check whether
they can cope up with the removal of stop_machine() or whether they need to
use new locks for synchronization (all CPU_DYING notifiers looked OK, without
the need for any new locks).
Applies on current mainline (v3.8-rc7+).
This patchset is available in the following git branch:
git://github.com/srivatsabhat/linux.git stop-machine-free-cpu-hotplug-v6
Overview of the patches:
-----------------------
Patches 1 to 7 introduce a generic, flexible Per-CPU Reader-Writer Locking
scheme.
Patch 8 uses this synchronization mechanism to build the
get/put_online_cpus_atomic() APIs which can be used from atomic context, to
prevent CPUs from going offline.
Patch 9 is a cleanup; it converts preprocessor macros to static inline
functions.
Patches 10 to 43 convert various call-sites to use the new APIs.
Patch 44 is the one which actually removes stop_machine() from the CPU
offline path.
Patch 45 decouples stop_machine() and CPU hotplug from Kconfig.
Patch 46 updates the documentation to reflect the new APIs.
Changes in v6:
--------------
* Fixed issues related to memory barriers, as pointed out by Paul and Oleg.
* Fixed the locking issue related to clockevents_lock, which was being
triggered when cpu idle was enabled.
* Some code restructuring to improve readability and to enhance some fastpath
optimizations.
* Randconfig build-fixes, reported by Fengguang Wu.
Changes in v5:
--------------
Exposed a new generic locking scheme: Flexible Per-CPU Reader-Writer locks,
based on the synchronization schemes already discussed in the previous
versions, and used it in CPU hotplug, to implement the new APIs.
Audited the CPU_DYING notifiers in the kernel source tree and replaced
usages of preempt_disable() with the new get/put_online_cpus_atomic() APIs
where necessary.
Changes in v4:
--------------
The synchronization scheme has been simplified quite a bit, which makes it
look a lot less complex than before. Some highlights:
* Implicit ACKs:
The earlier design required the readers to explicitly ACK the writer's
signal. The new design uses implicit ACKs instead. The reader switching
over to rwlock implicitly tells the writer to stop waiting for that reader.
* No atomic operations:
Since we got rid of explicit ACKs, we no longer have the need for a reader
and a writer to update the same counter. So we can get rid of atomic ops
too.
Changes in v3:
--------------
* Dropped the _light() and _full() variants of the APIs. Provided a single
interface: get/put_online_cpus_atomic().
* Completely redesigned the synchronization mechanism again, to make it
fast and scalable at the reader-side in the fast-path (when no hotplug
writers are active). This new scheme also ensures that there is no
possibility of deadlocks due to circular locking dependency.
In summary, this provides the scalability and speed of per-cpu rwlocks
(without actually using them), while avoiding the downside (deadlock
possibilities) which is inherent in any per-cpu locking scheme that is
meant to compete with preempt_disable()/enable() in terms of flexibility.
The problem with using per-cpu locking to replace preempt_disable()/enable
was explained here:
https://lkml.org/lkml/2012/12/6/290
Basically we use per-cpu counters (for scalability) when no writers are
active, and then switch to global rwlocks (for lock-safety) when a writer
becomes active. It is a slightly complex scheme, but it is based on
standard principles of distributed algorithms.
Changes in v2:
-------------
* Completely redesigned the synchronization scheme to avoid using any extra
cpumasks.
* Provided APIs for 2 types of atomic hotplug readers: "light" (for
light-weight) and "full". We wish to have more "light" readers than
the "full" ones, to avoid indirectly inducing the "stop_machine effect"
without even actually using stop_machine().
And the patches show that it _is_ generally true: 5 patches deal with
"light" readers, whereas only 1 patch deals with a "full" reader.
Also, the "light" readers happen to be in very hot paths. So it makes a
lot of sense to have such a distinction and a corresponding light-weight
API.
Links to previous versions:
v5: http://lwn.net/Articles/533553/
v4: https://lkml.org/lkml/2012/12/11/209
v3: https://lkml.org/lkml/2012/12/7/287
v2: https://lkml.org/lkml/2012/12/5/322
v1: https://lkml.org/lkml/2012/12/4/88
--
Paul E. McKenney (1):
cpu: No more __stop_machine() in _cpu_down()
Srivatsa S. Bhat (45):
percpu_rwlock: Introduce the global reader-writer lock backend
percpu_rwlock: Introduce per-CPU variables for the reader and the writer
percpu_rwlock: Provide a way to define and init percpu-rwlocks at compile time
percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
percpu_rwlock: Make percpu-rwlocks IRQ-safe, optimally
percpu_rwlock: Rearrange the read-lock code to fastpath nested percpu readers
percpu_rwlock: Allow writers to be readers, and add lockdep annotations
CPU hotplug: Provide APIs to prevent CPU offline from atomic context
CPU hotplug: Convert preprocessor macros to static inline functions
smp, cpu hotplug: Fix smp_call_function_*() to prevent CPU offline properly
smp, cpu hotplug: Fix on_each_cpu_*() to prevent CPU offline properly
sched/timer: Use get/put_online_cpus_atomic() to prevent CPU offline
sched/migration: Use raw_spin_lock/unlock since interrupts are already disabled
sched/rt: Use get/put_online_cpus_atomic() to prevent CPU offline
tick: Use get/put_online_cpus_atomic() to prevent CPU offline
time/clocksource: Use get/put_online_cpus_atomic() to prevent CPU offline
clockevents: Use get/put_online_cpus_atomic() in clockevents_notify()
softirq: Use get/put_online_cpus_atomic() to prevent CPU offline
irq: Use get/put_online_cpus_atomic() to prevent CPU offline
net: Use get/put_online_cpus_atomic() to prevent CPU offline
block: Use get/put_online_cpus_atomic() to prevent CPU offline
crypto: pcrypt - Protect access to cpu_online_mask with get/put_online_cpus()
infiniband: ehca: Use get/put_online_cpus_atomic() to prevent CPU offline
[SCSI] fcoe: Use get/put_online_cpus_atomic() to prevent CPU offline
staging: octeon: Use get/put_online_cpus_atomic() to prevent CPU offline
x86: Use get/put_online_cpus_atomic() to prevent CPU offline
perf/x86: Use get/put_online_cpus_atomic() to prevent CPU offline
KVM: Use get/put_online_cpus_atomic() to prevent CPU offline from atomic context
kvm/vmx: Use get/put_online_cpus_atomic() to prevent CPU offline
x86/xen: Use get/put_online_cpus_atomic() to prevent CPU offline
alpha/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
blackfin/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
cris/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
hexagon/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
ia64: Use get/put_online_cpus_atomic() to prevent CPU offline
m32r: Use get/put_online_cpus_atomic() to prevent CPU offline
MIPS: Use get/put_online_cpus_atomic() to prevent CPU offline
mn10300: Use get/put_online_cpus_atomic() to prevent CPU offline
parisc: Use get/put_online_cpus_atomic() to prevent CPU offline
powerpc: Use get/put_online_cpus_atomic() to prevent CPU offline
sh: Use get/put_online_cpus_atomic() to prevent CPU offline
sparc: Use get/put_online_cpus_atomic() to prevent CPU offline
tile: Use get/put_online_cpus_atomic() to prevent CPU offline
CPU hotplug, stop_machine: Decouple CPU hotplug from stop_machine() in Kconfig
Documentation/cpu-hotplug: Remove references to stop_machine()
Documentation/cpu-hotplug.txt | 17 +-
arch/alpha/kernel/smp.c | 19 +-
arch/arm/Kconfig | 1
arch/blackfin/Kconfig | 1
arch/blackfin/mach-common/smp.c | 6 -
arch/cris/arch-v32/kernel/smp.c | 8 +
arch/hexagon/kernel/smp.c | 5
arch/ia64/Kconfig | 1
arch/ia64/kernel/irq_ia64.c | 13 +
arch/ia64/kernel/perfmon.c | 6 +
arch/ia64/kernel/smp.c | 23 ++
arch/ia64/mm/tlb.c | 6 -
arch/m32r/kernel/smp.c | 12 +
arch/mips/Kconfig | 1
arch/mips/kernel/cevt-smtc.c | 8 +
arch/mips/kernel/smp.c | 16 +-
arch/mips/kernel/smtc.c | 3
arch/mips/mm/c-octeon.c | 4
arch/mn10300/Kconfig | 1
arch/mn10300/kernel/smp.c | 2
arch/mn10300/mm/cache-smp.c | 5
arch/mn10300/mm/tlb-smp.c | 15 +
arch/parisc/Kconfig | 1
arch/parisc/kernel/smp.c | 4
arch/powerpc/Kconfig | 1
arch/powerpc/mm/mmu_context_nohash.c | 2
arch/s390/Kconfig | 1
arch/sh/Kconfig | 1
arch/sh/kernel/smp.c | 12 +
arch/sparc/Kconfig | 1
arch/sparc/kernel/leon_smp.c | 2
arch/sparc/kernel/smp_64.c | 9 -
arch/sparc/kernel/sun4d_smp.c | 2
arch/sparc/kernel/sun4m_smp.c | 3
arch/tile/kernel/smp.c | 4
arch/x86/Kconfig | 1
arch/x86/include/asm/ipi.h | 5
arch/x86/kernel/apic/apic_flat_64.c | 10 +
arch/x86/kernel/apic/apic_numachip.c | 5
arch/x86/kernel/apic/es7000_32.c | 5
arch/x86/kernel/apic/io_apic.c | 7 -
arch/x86/kernel/apic/ipi.c | 10 +
arch/x86/kernel/apic/x2apic_cluster.c | 4
arch/x86/kernel/apic/x2apic_uv_x.c | 4
arch/x86/kernel/cpu/mcheck/therm_throt.c | 4
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 5
arch/x86/kvm/vmx.c | 8 +
arch/x86/mm/tlb.c | 14 +
arch/x86/xen/mmu.c | 11 +
arch/x86/xen/smp.c | 9 +
block/blk-softirq.c | 4
crypto/pcrypt.c | 4
drivers/infiniband/hw/ehca/ehca_irq.c | 8 +
drivers/scsi/fcoe/fcoe.c | 7 +
drivers/staging/octeon/ethernet-rx.c | 3
include/linux/cpu.h | 8 +
include/linux/percpu-rwlock.h | 74 +++++++
include/linux/stop_machine.h | 2
init/Kconfig | 2
kernel/cpu.c | 59 +++++-
kernel/irq/manage.c | 7 +
kernel/sched/core.c | 36 +++-
kernel/sched/fair.c | 5
kernel/sched/rt.c | 3
kernel/smp.c | 65 ++++--
kernel/softirq.c | 3
kernel/time/clockevents.c | 3
kernel/time/clocksource.c | 5
kernel/time/tick-broadcast.c | 2
kernel/timer.c | 2
lib/Kconfig | 3
lib/Makefile | 1
lib/percpu-rwlock.c | 256 +++++++++++++++++++++++++
net/core/dev.c | 9 +
virt/kvm/kvm_main.c | 10 +
75 files changed, 776 insertions(+), 123 deletions(-)
create mode 100644 include/linux/percpu-rwlock.h
create mode 100644 lib/percpu-rwlock.c
Regards,
Srivatsa S. Bhat
IBM Linux Technology Center
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:40:49
A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
locks can also lead to too many deadlock possibilities which can make it very
hard/impossible to use. This is explained in the example below, which helps
justify the need for a different algorithm to implement flexible Per-CPU
Reader-Writer locks.
We can use global rwlocks as shown below safely, without fear of deadlocks:
Readers:
CPU 0 CPU 1
------ ------
1. spin_lock(&random_lock); read_lock(&my_rwlock);
2. read_lock(&my_rwlock); spin_lock(&random_lock);
Writer:
CPU 2:
------
write_lock(&my_rwlock);
We can observe that there is no possibility of deadlocks or circular locking
dependencies here. Its perfectly safe.
Now consider a blind/straight-forward conversion of global rwlocks to per-CPU
rwlocks like this:
The reader locks its own per-CPU rwlock for read, and proceeds.
Something like: read_lock(per-cpu rwlock of this cpu);
The writer acquires all per-CPU rwlocks for write and only then proceeds.
Something like:
for_each_online_cpu(cpu)
write_lock(per-cpu rwlock of 'cpu');
Now let's say that for performance reasons, the above scenario (which was
perfectly safe when using global rwlocks) was converted to use per-CPU rwlocks.
CPU 0 CPU 1
------ ------
1. spin_lock(&random_lock); read_lock(my_rwlock of CPU 1);
2. read_lock(my_rwlock of CPU 0); spin_lock(&random_lock);
Writer:
CPU 2:
------
for_each_online_cpu(cpu)
write_lock(my_rwlock of 'cpu');
Consider what happens if the writer begins his operation in between steps 1
and 2 at the reader side. It becomes evident that we end up in a (previously
non-existent) deadlock due to a circular locking dependency between the 3
entities, like this:
(holds Waiting for
random_lock) CPU 0 -------------> CPU 2 (holds my_rwlock of CPU 0
for write)
^ |
| |
Waiting| | Waiting
for | | for
| V
------ CPU 1 <------
(holds my_rwlock of
CPU 1 for read)
So obviously this "straight-forward" way of implementing percpu rwlocks is
deadlock-prone. One simple measure for (or characteristic of) safe percpu
rwlock should be that if a user replaces global rwlocks with per-CPU rwlocks
(for performance reasons), he shouldn't suddenly end up in numerous deadlock
possibilities which never existed before. The replacement should continue to
remain safe, and perhaps improve the performance.
Observing the robustness of global rwlocks in providing a fair amount of
deadlock safety, we implement per-CPU rwlocks as nothing but global rwlocks,
as a first step.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
include/linux/percpu-rwlock.h | 49 ++++++++++++++++++++++++++++++++
lib/Kconfig | 3 ++
lib/Makefile | 1 +
lib/percpu-rwlock.c | 63 +++++++++++++++++++++++++++++++++++++++++
4 files changed, 116 insertions(+)
create mode 100644 include/linux/percpu-rwlock.h
create mode 100644 lib/percpu-rwlock.c
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:40:56
Per-CPU rwlocks ought to give better performance than global rwlocks.
That is where the "per-CPU" component comes in. So introduce the necessary
per-CPU variables that would be necessary at the reader and the writer sides,
and add the support for dynamically initializing per-CPU rwlocks.
These per-CPU variables will be used subsequently to implement the core
algorithm behind per-CPU rwlocks.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
include/linux/percpu-rwlock.h | 8 ++++++++
lib/percpu-rwlock.c | 12 ++++++++++++
2 files changed, 20 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:41:01
Add the support for defining and initializing percpu-rwlocks at compile time
for those users who would like to use percpu-rwlocks really early in the boot
process (even before dynamic per-CPU allocations can begin).
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
include/linux/percpu-rwlock.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:41:11
Using global rwlocks as the backend for per-CPU rwlocks helps us avoid many
lock-ordering related problems (unlike per-cpu locks). However, global
rwlocks lead to unnecessary cache-line bouncing even when there are no
writers present, which can slow down the system needlessly.
Per-cpu counters can help solve the cache-line bouncing problem. So we
actually use the best of both: per-cpu counters (no-waiting) at the reader
side in the fast-path, and global rwlocks in the slowpath.
[ Fastpath = no writer is active; Slowpath = a writer is active ]
IOW, the readers just increment/decrement their per-cpu refcounts (disabling
interrupts during the updates, if necessary) when no writer is active.
When a writer becomes active, he signals all readers to switch to global
rwlocks for the duration of his activity. The readers switch over when it
is safe for them (ie., when they are about to start a fresh, non-nested
read-side critical section) and start using (holding) the global rwlock for
read in their subsequent critical sections.
The writer waits for every existing reader to switch, and then acquires the
global rwlock for write and enters his critical section. Later, the writer
signals all readers that he is done, and that they can go back to using their
per-cpu refcounts again.
Note that the lock-safety (despite the per-cpu scheme) comes from the fact
that the readers can *choose* _when_ to switch to rwlocks upon the writer's
signal. And the readers don't wait on anybody based on the per-cpu counters.
The only true synchronization that involves waiting at the reader-side in this
scheme, is the one arising from the global rwlock, which is safe from circular
locking dependency issues.
Reader-writer locks and per-cpu counters are recursive, so they can be
used in a nested fashion in the reader-path, which makes per-CPU rwlocks also
recursive. Also, this design of switching the synchronization scheme ensures
that you can safely nest and use these locks in a very flexible manner.
I'm indebted to Michael Wang and Xiao Guangrong for their numerous thoughtful
suggestions and ideas, which inspired and influenced many of the decisions in
this as well as previous designs. Thanks a lot Michael and Xiao!
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
lib/percpu-rwlock.c | 139 ++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 137 insertions(+), 2 deletions(-)
@@ -55,21 +73,138 @@ void percpu_free_rwlock(struct percpu_rwlock *pcpu_rwlock)voidpercpu_read_lock(structpercpu_rwlock*pcpu_rwlock){-read_lock(&pcpu_rwlock->global_rwlock);+preempt_disable();++/*+*Letthewriterknowthatareaderisactive,evenbeforewechoose+*ourreader-sidesynchronizationscheme.+*/+this_cpu_inc(pcpu_rwlock->rw_state->reader_refcnt);++/*+*Ifwearealreadyusingper-cpurefcounts,itisnotsafetoswitch+*thesynchronizationscheme.Socontinueusingtherefcounts.+*/+if(reader_nested_percpu(pcpu_rwlock))+return;++/*+*Thewriteto'reader_refcnt'mustbevisiblebeforeweread+*'writer_signal'.+*/+smp_mb();++if(likely(!writer_active(pcpu_rwlock))){+gotoout;+}else{+/* Writer is active, so switch to global rwlock. */+read_lock(&pcpu_rwlock->global_rwlock);++/*+*Wemighthaveracedwithawritergoinginactivebeforewe+*tooktheread-lock.Sore-evaluatewhetherwestillneedto+*holdtherwlockorifwecanswitchbacktoper-cpu+*refcounts.(Thisalsohelpsavoidheterogeneousnestingof+*readers).+*/+if(writer_active(pcpu_rwlock)){+/*+*Theabovewriter_active()checkcangetreordered+*withthis_cpu_dec()below,butthisisOK,because+*holdingtherwlockisconservative.+*/+this_cpu_dec(pcpu_rwlock->rw_state->reader_refcnt);+}else{+read_unlock(&pcpu_rwlock->global_rwlock);+}+}++out:+/* Prevent reordering of any subsequent reads/writes */+smp_mb();}voidpercpu_read_unlock(structpercpu_rwlock*pcpu_rwlock){-read_unlock(&pcpu_rwlock->global_rwlock);+/*+*Weneverallowheterogeneousnestingofreaders.Soitistrivial+*tofindoutthekindofreaderweare,andundotheoperation+*donebyourcorrespondingpercpu_read_lock().+*/++/* Try to fast-path: a nested percpu reader is the simplest case */+if(reader_nested_percpu(pcpu_rwlock)){+this_cpu_dec(pcpu_rwlock->rw_state->reader_refcnt);+preempt_enable();+return;+}++/*+*Nowweareleftwithonly2options:anon-nestedpercpureader,+*orareaderholdingrwlock+*/+if(reader_uses_percpu_refcnt(pcpu_rwlock)){+/*+*Completethecriticalsectionbeforedecrementingthe+*refcnt.Wecanoptimizethisawayifweareanested+*reader(thecaseabove).+*/+smp_mb();+this_cpu_dec(pcpu_rwlock->rw_state->reader_refcnt);+}else{+read_unlock(&pcpu_rwlock->global_rwlock);+}++preempt_enable();}voidpercpu_write_lock(structpercpu_rwlock*pcpu_rwlock){+unsignedintcpu;++/*+*Tellallreadersthatawriterisbecomingactive,sothatthey+*startswitchingovertotheglobalrwlock.+*/+for_each_possible_cpu(cpu)+per_cpu_ptr(pcpu_rwlock->rw_state,cpu)->writer_signal=true;++smp_mb();++/*+*Waitforeveryreadertoseethewriter'ssignalandswitchfrom+*percpurefcountstoglobalrwlock.+*+*Ifareaderisstillusingpercpurefcounts,waitforhimtoswitch.+*Else,wecansafelygoahead,becauseeitherthereaderhasalready+*switchedover,orthenextreaderthatcomesalongonthatCPUwill+*noticethewriter'ssignalandwillswitchovertotherwlock.+*/++for_each_possible_cpu(cpu){+while(reader_yet_to_switch(pcpu_rwlock,cpu))+cpu_relax();+}++smp_mb();/* Complete the wait-for-readers, before taking the lock */write_lock(&pcpu_rwlock->global_rwlock);}voidpercpu_write_unlock(structpercpu_rwlock*pcpu_rwlock){+unsignedintcpu;++/* Complete the critical section before clearing ->writer_signal */+smp_mb();++/*+*Informallreadersthatwearedone,sothattheycanswitchback+*totheirper-cpurefcounts.(Wedon'tneedtowaitforthemto+*seeit).+*/+for_each_possible_cpu(cpu)+per_cpu_ptr(pcpu_rwlock->rw_state,cpu)->writer_signal=false;+write_unlock(&pcpu_rwlock->global_rwlock);}
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:41:23
If we are dealing with a nester percpu reader, we can optimize away quite
a few costly operations. Improve that fastpath further, by avoiding the
unnecessary addition and subtraction of 'READER_PRESENT' to reader_refcnt,
by rearranging the code a bit.
Signed-off-by: Srivatsa S. Bhat <redacted>
---
lib/percpu-rwlock.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:41:33
CPU hotplug (which will be the first user of per-CPU rwlocks) has a special
requirement with respect to locking: the writer, after acquiring the per-CPU
rwlock for write, must be allowed to take the same lock for read, without
deadlocking and without getting complaints from lockdep. In comparison, this
is similar to what get_online_cpus()/put_online_cpus() does today: it allows
a hotplug writer (who holds the cpu_hotplug.lock mutex) to invoke it without
locking issues, because it silently returns if the caller is the hotplug
writer itself.
This can be easily achieved with per-CPU rwlocks as well (even without a
"is this a writer?" check) by incrementing the per-CPU refcount of the writer
immediately after taking the global rwlock for write, and then decrementing
the per-CPU refcount before releasing the global rwlock.
This ensures that any reader that comes along on that CPU while the writer is
active (on that same CPU), notices the non-zero value of the nested counter
and assumes that it is a nested read-side critical section and proceeds by
just incrementing the refcount. Thus we prevent the reader from taking the
global rwlock for read, which prevents the writer from deadlocking itself.
Add that support and teach lockdep about this special locking scheme so
that it knows that this sort of usage is valid. Also add the required lockdep
annotations to enable it to detect common locking problems with per-CPU
rwlocks.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
lib/percpu-rwlock.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
@@ -102,6 +102,10 @@ void percpu_read_lock_irqsafe(struct percpu_rwlock *pcpu_rwlock)if(likely(!writer_active(pcpu_rwlock))){this_cpu_inc(pcpu_rwlock->rw_state->reader_refcnt);++/* Pretend that we take global_rwlock for lockdep */+rwlock_acquire_read(&pcpu_rwlock->global_rwlock.dep_map,+0,0,_RET_IP_);}else{/* Writer is active, so switch to global rwlock. */
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:41:44
On 12/05/2012 06:10 AM, Andrew Morton wrote:
"static inline C functions would be preferred if possible. Feel free to
fix up the wrong crufty surrounding code as well ;-)"
Convert the macros in the CPU hotplug code to static inline C functions.
Signed-off-by: Srivatsa S. Bhat <redacted>
Reviewed-by: Paul E. McKenney <redacted>
---
include/linux/cpu.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
@@ -198,10 +198,10 @@ static inline void cpu_hotplug_driver_unlock(void)#else /* CONFIG_HOTPLUG_CPU */-#define get_online_cpus() do { } while (0)-#define put_online_cpus() do { } while (0)-#define get_online_cpus_atomic() do { } while (0)-#define put_online_cpus_atomic() do { } while (0)+staticinlinevoidget_online_cpus(void){}+staticinlinevoidput_online_cpus(void){}+staticinlinevoidget_online_cpus_atomic(void){}+staticinlinevoidput_online_cpus_atomic(void){}#define hotcpu_notifier(fn, pri) do { (void)(fn); } while (0)/* These aren't inline functions due to a GCC bug. */#define register_hotcpu_notifier(nb) ({ (void)(nb); 0; })
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:41:52
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() to prevent CPUs from going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/smp.c | 40 ++++++++++++++++++++++++++--------------
1 file changed, 26 insertions(+), 14 deletions(-)
@@ -376,8 +377,10 @@ int smp_call_function_any(const struct cpumask *mask,conststructcpumask*nodemask;intret;+get_online_cpus_atomic();/* Try for same CPU (cheapest) */-cpu=get_cpu();+cpu=smp_processor_id();+if(cpumask_test_cpu(cpu,mask))gotocall;
@@ -393,7 +396,7 @@ int smp_call_function_any(const struct cpumask *mask,cpu=cpumask_any_and(mask,cpu_online_mask);call:ret=smp_call_function_single(cpu,func,info,wait);-put_cpu();+put_online_cpus_atomic();returnret;}EXPORT_SYMBOL_GPL(smp_call_function_any);
@@ -472,17 +480,18 @@ void smp_call_function_many(const struct cpumask *mask,/* No online cpus? We're done. */if(cpu>=nr_cpu_ids)-return;+gotoout_unlock;/* Do we have another CPU which isn't us? */next_cpu=cpumask_next_and(cpu,mask,cpu_online_mask);if(next_cpu==this_cpu)-next_cpu=cpumask_next_and(next_cpu,mask,cpu_online_mask);+next_cpu=cpumask_next_and(next_cpu,mask,+cpu_online_mask);/* Fastpath: do that cpu by itself. */if(next_cpu>=nr_cpu_ids){smp_call_function_single(cpu,func,info,wait);-return;+gotoout_unlock;}data=&__get_cpu_var(cfd_data);
@@ -528,7 +537,7 @@ void smp_call_function_many(const struct cpumask *mask,/* Some callers race with other cpus changing the passed mask */if(unlikely(!refs)){csd_unlock(&data->csd);-return;+gotoout_unlock;}/*
@@ -565,6 +574,9 @@ void smp_call_function_many(const struct cpumask *mask,/* Optionally wait for the CPUs to complete */if(wait)csd_lock_wait(&data->csd);++out_unlock:+put_online_cpus_atomic();}EXPORT_SYMBOL(smp_call_function_many);
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:42:07
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() to prevent CPUs from going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/smp.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:42:14
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from going
offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/sched/core.c | 24 +++++++++++++++++++++---
kernel/sched/fair.c | 5 ++++-
kernel/timer.c | 2 ++
3 files changed, 27 insertions(+), 4 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:42:20
We need not use the raw_spin_lock_irqsave/restore primitives because
all CPU_DYING notifiers run with interrupts disabled. So just use
raw_spin_lock/unlock.
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/sched/core.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:42:28
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/sched/rt.c | 3 +++
1 file changed, 3 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:42:33
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/time/tick-broadcast.c | 2 ++
1 file changed, 2 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:42:45
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from going
offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: John Stultz <redacted>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/time/clocksource.c | 5 +++++
1 file changed, 5 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:42:52
The cpu idle code invokes clockevents_notify() during idle state transitions
and the cpu offline code invokes it during the CPU_DYING phase. There
seems to be a race-condition between the two, where the clockevents_lock
never gets released, ending in a lockup. This can be fixed by synchronizing
clockevents_notify() with CPU offline, by wrapping its contents within
get/put_online_cpus_atomic().
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/time/clockevents.c | 3 +++
1 file changed, 3 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:42:59
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Frederic Weisbecker <redacted>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/softirq.c | 3 +++
1 file changed, 3 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:43:08
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/irq/manage.c | 7 +++++++
1 file changed, 7 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:43:30
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
block/blk-softirq.c | 4 ++++
1 file changed, 4 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:43:32
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
net/core/dev.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:43:44
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Robert Love <redacted>
Cc: "James E.J. Bottomley" <redacted>
Cc: devel@open-fcoe.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
drivers/scsi/fcoe/fcoe.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:43:52
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: David Daney <redacted>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
drivers/staging/octeon/ethernet-rx.c | 3 +++
1 file changed, 3 insertions(+)
@@ -97,6 +98,7 @@ static void cvm_oct_enable_one_cpu(void)return;/* ... if a CPU is available, Turn on NAPI polling for that CPU. */+get_online_cpus_atomic();for_each_online_cpu(cpu){if(!cpu_test_and_set(cpu,core_state.cpu_state)){v=smp_call_function_single(cpu,cvm_oct_enable_napi,
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:44:08
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Tony Luck <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Daniel J Blueman <redacted>
Cc: Steffen Persvold <redacted>
Cc: Joerg Roedel <redacted>
Cc: linux-edac@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/x86/include/asm/ipi.h | 5 +++++
arch/x86/kernel/apic/apic_flat_64.c | 10 ++++++++++
arch/x86/kernel/apic/apic_numachip.c | 5 +++++
arch/x86/kernel/apic/es7000_32.c | 5 +++++
arch/x86/kernel/apic/io_apic.c | 7 +++++--
arch/x86/kernel/apic/ipi.c | 10 ++++++++++
arch/x86/kernel/apic/x2apic_cluster.c | 4 ++++
arch/x86/kernel/apic/x2apic_uv_x.c | 4 ++++
arch/x86/kernel/cpu/mcheck/therm_throt.c | 4 ++--
arch/x86/mm/tlb.c | 14 +++++++-------
10 files changed, 57 insertions(+), 11 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:44:19
The CPU_DYING notifier modifies the per-cpu pointer pmu->box, and this can
race with functions such as uncore_pmu_to_box() and uncore_pci_remove() when
we remove stop_machine() from the CPU offline path. So protect them using
get/put_online_cpus_atomic().
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Arnaldo Carvalho de Melo <redacted>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 5 +++++
1 file changed, 5 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:44:29
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Marcelo Tosatti <redacted>
Cc: Gleb Natapov <redacted>
Cc: kvm@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
virt/kvm/kvm_main.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:44:37
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context (in vmx_vcpu_load() to prevent CPUs from
going offline while clearing vmcs).
Reported-by: Michael Wang <redacted>
Debugged-by: Xiao Guangrong [off-list ref]
Cc: Marcelo Tosatti <redacted>
Cc: Gleb Natapov <redacted>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/x86/kvm/vmx.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
@@ -1557,10 +1557,14 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)structvcpu_vmx*vmx=to_vmx(vcpu);u64phys_addr=__pa(per_cpu(vmxarea,cpu));-if(!vmm_exclusive)+if(!vmm_exclusive){kvm_cpu_vmxon(phys_addr);-elseif(vmx->loaded_vmcs->cpu!=cpu)+}elseif(vmx->loaded_vmcs->cpu!=cpu){+/* Prevent any CPU from going offline */+get_online_cpus_atomic();loaded_vmcs_clear(vmx->loaded_vmcs);+put_online_cpus_atomic();+}if(per_cpu(current_vmcs,cpu)!=vmx->loaded_vmcs->vmcs){per_cpu(current_vmcs,cpu)=vmx->loaded_vmcs->vmcs;
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:44:42
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Konrad Rzeszutek Wilk <redacted>
Cc: Jeremy Fitzhardinge <redacted>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/x86/xen/mmu.c | 11 +++++++++--
arch/x86/xen/smp.c | 9 +++++++++
2 files changed, 18 insertions(+), 2 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:44:53
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Also, remove the non-ASCII character present in this file!
Cc: linux-alpha@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/alpha/kernel/smp.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:44:59
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Mike Frysinger <redacted>
Cc: Bob Liu <redacted>
Cc: Steven Miao <redacted>
Cc: uclinux-dist-devel@blackfin.uclinux.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/blackfin/mach-common/smp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:45:12
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Mikael Starvik <redacted>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: linux-cris-kernel@axis.com
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/cris/arch-v32/kernel/smp.c | 8 ++++++++
1 file changed, 8 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:45:21
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Richard Kuo <redacted>
Cc: linux-hexagon@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/hexagon/kernel/smp.c | 5 +++++
1 file changed, 5 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:45:27
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <redacted>
Cc: linux-ia64@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/ia64/kernel/irq_ia64.c | 13 +++++++++++++
arch/ia64/kernel/perfmon.c | 6 ++++++
arch/ia64/kernel/smp.c | 23 ++++++++++++++++-------
arch/ia64/mm/tlb.c | 6 ++++--
4 files changed, 39 insertions(+), 9 deletions(-)
@@ -302,9 +307,11 @@ int irq_prepare_move(int irq, int cpu)unsignedlongflags;intret;+get_online_cpus_atomic();spin_lock_irqsave(&vector_lock,flags);ret=__irq_prepare_move(irq,cpu);spin_unlock_irqrestore(&vector_lock,flags);+put_online_cpus_atomic();returnret;}
@@ -293,12 +301,13 @@ voidsmp_flush_tlb_mm(structmm_struct*mm){cpumask_var_tcpus;-preempt_disable();++get_online_cpus_atomic();/* this happens for the common case of a single-threaded fork(): */if(likely(mm==current->active_mm&&atomic_read(&mm->mm_users)==1)){local_finish_flush_tlb_mm(mm);-preempt_enable();+put_online_cpus_atomic();return;}if(!alloc_cpumask_var(&cpus,GFP_ATOMIC)){
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:45:40
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs fom
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Ralf Baechle <redacted>
Cc: David Daney <redacted>
Cc: linux-mips@linux-mips.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/mips/kernel/cevt-smtc.c | 8 ++++++++
arch/mips/kernel/smp.c | 16 ++++++++--------
arch/mips/kernel/smtc.c | 3 +++
arch/mips/mm/c-octeon.c | 4 ++--
4 files changed, 21 insertions(+), 10 deletions(-)
@@ -84,6 +85,8 @@ static int mips_next_event(unsigned long delta,unsignedlongnextcomp=0L;intvpe=current_cpu_data.vpe_id;intcpu=smp_processor_id();++get_online_cpus_atomic();local_irq_save(flags);mtflags=dmt();
@@ -164,6 +167,7 @@ static int mips_next_event(unsigned long delta,}emt(mtflags);local_irq_restore(flags);+put_online_cpus_atomic();return0;}
@@ -221,6 +226,9 @@ repeat:}}++put_online_cpus_atomic()+/* Reprogram for interrupt at next soonest timestamp for VPE */if(ISVALID(nextstamp)){write_c0_compare(nextstamp);
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:45:47
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: David Howells <dhowells@redhat.com>
Cc: Koichi Yasutake <redacted>
Cc: linux-am33-list@redhat.com
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/mn10300/kernel/smp.c | 2 ++
arch/mn10300/mm/cache-smp.c | 5 +++++
arch/mn10300/mm/tlb-smp.c | 15 +++++++++------
3 files changed, 16 insertions(+), 6 deletions(-)
@@ -94,6 +95,8 @@ void smp_cache_call(unsigned long opr_mask,smp_cache_mask=opr_mask;smp_cache_start=start;smp_cache_end=end;++get_online_cpus_atomic();cpumask_copy(&smp_cache_ipi_map,cpu_online_mask);cpumask_clear_cpu(smp_processor_id(),&smp_cache_ipi_map);
@@ -102,4 +105,6 @@ void smp_cache_call(unsigned long opr_mask,while(!cpumask_empty(&smp_cache_ipi_map))/* nothing. lockup detection does not belong here */mb();++put_online_cpus_atomic();}
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:45:54
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: "James E.J. Bottomley" <redacted>
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/parisc/kernel/smp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:46:09
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <redacted>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/powerpc/mm/mmu_context_nohash.c | 2 ++
1 file changed, 2 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:46:24
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Sam Ravnborg <redacted>
Cc: sparclinux@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/sparc/kernel/leon_smp.c | 2 ++
arch/sparc/kernel/smp_64.c | 9 +++++----
arch/sparc/kernel/sun4d_smp.c | 2 ++
arch/sparc/kernel/sun4m_smp.c | 3 +++
4 files changed, 12 insertions(+), 4 deletions(-)
@@ -420,6 +420,7 @@ static void leon_cross_call(smpfunc_t func, cpumask_t mask, unsigned long arg1,unsignedlongflags;spin_lock_irqsave(&cross_call_lock,flags);+get_online_cpus_atomic();{/* If you make changes here, make sure gcc generates proper code... */
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:46:34
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Chris Metcalf <redacted>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/tile/kernel/smp.c | 4 ++++
1 file changed, 4 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:46:46
From: Paul E. McKenney <redacted>
The _cpu_down() function invoked as part of the CPU-hotplug offlining
process currently invokes __stop_machine(), which is slow and inflicts
substantial real-time latencies on the entire system. This patch
substitutes stop_one_cpu() for __stop_machine() in order to improve
both performance and real-time latency.
There were a number of uses of preempt_disable() or local_irq_disable()
that were intended to block CPU-hotplug offlining. These were fixed by
using get/put_online_cpus_atomic(), which is the new synchronization
primitive to prevent CPU offline, while invoking from atomic context.
Signed-off-by: Paul E. McKenney <redacted>
Signed-off-by: Paul E. McKenney <redacted>
[ srivatsa.bhat@linux.vnet.ibm.com: Refer to the new sync primitives for
readers (in the changelog); s/stop_cpus/stop_one_cpu and fix comment
referring to stop_machine in the code]
Signed-off-by: Srivatsa S. Bhat <redacted>
---
kernel/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -337,7 +337,7 @@ static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)}smpboot_park_threads(cpu);-err=__stop_machine(take_cpu_down,&tcd_param,cpumask_of(cpu));+err=stop_one_cpu(cpu,take_cpu_down,&tcd_param);if(err){/* CPU didn't die: tell everyone. Can't complain. */smpboot_unpark_threads(cpu);
@@ -349,7 +349,7 @@ static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)/**Themigration_call()CPU_DYINGcallbackwillhaveremovedall*runnabletasksfromthecpu,there'sonlytheidletaskleftnow-*thatthemigrationthreadisdonedoingthestop_machinething.+*thatthemigrationthreadisdonedoingthestop_one_cpu()thing.**Waitforthestopthreadtogoaway.*/
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:46:53
Simply dropping HOTPLUG_CPU from the dependency list of STOP_MACHINE will
lead to the following kconfig issue, reported by Fengguang Wu:
"warning: (HAVE_TEXT_POKE_SMP) selects STOP_MACHINE which has unmet direct
dependencies (SMP && MODULE_UNLOAD)"
So drop HOTPLUG_CPU and add HAVE_TEXT_POKE_SMP to the dependency list of
STOP_MACHINE.
And while at it, also cleanup a comment that refers to CPU hotplug being
dependent on stop_machine().
Cc: David Howells <dhowells@redhat.com>
Reported-by: Fengguang Wu <redacted>
Suggested-by: Masami Hiramatsu <redacted>
Signed-off-by: Srivatsa S. Bhat <redacted>
Reviewed-by: Paul E. McKenney <redacted>
---
include/linux/stop_machine.h | 2 +-
init/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:47:00
Since stop_machine() is no longer used in the CPU offline path, we cannot
disable CPU hotplug using preempt_disable()/local_irq_disable() etc. We
need to use the newly introduced get/put_online_cpus_atomic() APIs.
Reflect this in the documentation.
Cc: Rob Landley <redacted>
Cc: linux-doc@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
Reviewed-by: Paul E. McKenney <redacted>
---
Documentation/cpu-hotplug.txt | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
@@ -113,13 +113,15 @@ Never use anything other than cpumask_t to represent bitmap of CPUs. #include <linux/cpu.h> get_online_cpus() and put_online_cpus():-The above calls are used to inhibit cpu hotplug operations. While the+The above calls are used to inhibit cpu hotplug operations, when invoked from+non-atomic context (because the above functions can sleep). While the cpu_hotplug.refcount is non zero, the cpu_online_mask will not change.-If you merely need to avoid cpus going away, you could also use-preempt_disable() and preempt_enable() for those sections.-Just remember the critical section cannot call any-function that can sleep or schedule this process away. The preempt_disable()-will work as long as stop_machine_run() is used to take a cpu down.++However, if you are executing in atomic context (ie., you can't afford to+sleep), and you merely need to avoid cpus going offline, you can use+get_online_cpus_atomic() and put_online_cpus_atomic() for those sections.+Just remember the critical section cannot call any function that can sleep or+schedule this process away. CPU Hotplug - Frequently Asked Questions.
@@ -360,6 +362,9 @@ A: There are two ways. If your code can be run in interrupt context, use return err; }+ If my_func_on_cpu() itself cannot block, use get/put_online_cpus_atomic()+ instead of get/put_online_cpus() to prevent CPUs from going offline.+ Q: How do we determine how many CPUs are available for hotplug. A: There is no clear spec defined way from ACPI that can give us that information today. Based on some input from Natalie of Unisys,
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:48:27
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Paul Mundt <redacted>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/sh/kernel/smp.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:49:20
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Hirokazu Takata <redacted>
Cc: linux-m32r@ml.linux-m32r.org
Cc: linux-m32r-ja@ml.linux-m32r.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
arch/m32r/kernel/smp.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:51:56
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Roland Dreier <roland@kernel.org>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
drivers/infiniband/hw/ehca/ehca_irq.c | 8 ++++++++
1 file changed, 8 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:52:40
The pcrypt_aead_init_tfm() function access the cpu_online_mask without
disabling CPU hotplug. And it looks like it can afford to sleep, so use
the get/put_online_cpus() APIs to protect against CPU hotplug.
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
---
crypto/pcrypt.c | 4 ++++
1 file changed, 4 insertions(+)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:56:00
There are places where preempt_disable() or local_irq_disable() are used
to prevent any CPU from going offline during the critical section. Let us
call them as "atomic hotplug readers" ("atomic" because they run in atomic,
non-preemptible contexts).
Today, preempt_disable() or its equivalent works because the hotplug writer
uses stop_machine() to take CPUs offline. But once stop_machine() is gone
from the CPU hotplug offline path, the readers won't be able to prevent
CPUs from going offline using preempt_disable().
So the intent here is to provide synchronization APIs for such atomic hotplug
readers, to prevent (any) CPUs from going offline, without depending on
stop_machine() at the writer-side. The new APIs will look something like
this: get_online_cpus_atomic() and put_online_cpus_atomic()
Some important design requirements and considerations:
-----------------------------------------------------
1. Scalable synchronization at the reader-side, especially in the fast-path
Any synchronization at the atomic hotplug readers side must be highly
scalable - avoid global single-holder locks/counters etc. Because, these
paths currently use the extremely fast preempt_disable(); our replacement
to preempt_disable() should not become ridiculously costly and also should
not serialize the readers among themselves needlessly.
At a minimum, the new APIs must be extremely fast at the reader side
atleast in the fast-path, when no CPU offline writers are active.
2. preempt_disable() was recursive. The replacement should also be recursive.
3. No (new) lock-ordering restrictions
preempt_disable() was super-flexible. It didn't impose any ordering
restrictions or rules for nesting. Our replacement should also be equally
flexible and usable.
4. No deadlock possibilities
Regular per-cpu locking is not the way to go if we want to have relaxed
rules for lock-ordering. Because, we can end up in circular-locking
dependencies as explained in https://lkml.org/lkml/2012/12/6/290
So, avoid the usual per-cpu locking schemes (per-cpu locks/per-cpu atomic
counters with spin-on-contention etc) as much as possible, to avoid
numerous deadlock possibilities from creeping in.
Implementation of the design:
----------------------------
We use per-CPU reader-writer locks for synchronization because:
a. They are quite fast and scalable in the fast-path (when no writers are
active), since they use fast per-cpu counters in those paths.
b. They are recursive at the reader side.
c. They provide a good amount of safety against deadlocks; they don't
spring new deadlock possibilities on us from out of nowhere. As a
result, they have relaxed locking rules and are quite flexible, and
thus are best suited for replacing usages of preempt_disable() or
local_irq_disable() at the reader side.
Together, these satisfy all the requirements mentioned above.
I'm indebted to Michael Wang and Xiao Guangrong for their numerous thoughtful
suggestions and ideas, which inspired and influenced many of the decisions in
this as well as previous designs. Thanks a lot Michael and Xiao!
Cc: Russell King <redacted>
Cc: Mike Frysinger <redacted>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Ralf Baechle <redacted>
Cc: David Howells <dhowells@redhat.com>
Cc: "James E.J. Bottomley" <redacted>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <redacted>
Cc: Paul Mundt <redacted>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: uclinux-dist-devel@blackfin.uclinux.org
Cc: linux-ia64@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-am33-list@redhat.com
Cc: linux-parisc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <redacted>
Reviewed-by: Paul E. McKenney <redacted>
---
arch/arm/Kconfig | 1 +
arch/blackfin/Kconfig | 1 +
arch/ia64/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/mn10300/Kconfig | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/s390/Kconfig | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/x86/Kconfig | 1 +
include/linux/cpu.h | 4 ++++
kernel/cpu.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++--
13 files changed, 68 insertions(+), 2 deletions(-)
@@ -198,6 +200,8 @@ static inline void cpu_hotplug_driver_unlock(void)#define get_online_cpus() do { } while (0)#define put_online_cpus() do { } while (0)+#define get_online_cpus_atomic() do { } while (0)+#define put_online_cpus_atomic() do { } while (0)#define hotcpu_notifier(fn, pri) do { (void)(fn); } while (0)/* These aren't inline functions due to a GCC bug. */#define register_hotcpu_notifier(nb) ({ (void)(nb); 0; })
@@ -246,15 +291,21 @@ struct take_cpu_down_param {staticint__reftake_cpu_down(void*_param){structtake_cpu_down_param*param=_param;+unsignedlongflags;interr;+percpu_write_lock_irqsave(&hotplug_pcpu_rwlock,&flags);+/* Ensure this CPU doesn't handle any more interrupts. */err=__cpu_disable();if(err<0)-returnerr;+gotoout;cpu_notify(CPU_DYING|param->mod,param->hcpu);-return0;++out:+percpu_write_unlock_irqrestore(&hotplug_pcpu_rwlock,&flags);+returnerr;}/* Requires cpu_add_remove_lock to be held */
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 12:56:55
If interrupt handlers can also be readers, then one of the ways to make
per-CPU rwlocks safe, is to disable interrupts at the reader side before
trying to acquire the per-CPU rwlock and keep it disabled throughout the
duration of the read-side critical section.
The goal is to avoid cases such as:
1. writer is active and it holds the global rwlock for write
2. a regular reader comes in and marks itself as present (by incrementing
its per-CPU refcount) before checking whether writer is active.
3. an interrupt hits the reader;
[If it had not hit, the reader would have noticed that the writer is
active and would have decremented its refcount and would have tried
to acquire the global rwlock for read].
Since the interrupt handler also happens to be a reader, it notices
the non-zero refcount (which was due to the reader who got interrupted)
and thinks that this is a nested read-side critical section and
proceeds to take the fastpath, which is wrong. The interrupt handler
should have noticed that the writer is active and taken the rwlock
for read.
So, disabling interrupts can help avoid this problem (at the cost of keeping
the interrupts disabled for quite long).
But Oleg had a brilliant idea by which we can do much better than that:
we can manage with disabling interrupts _just_ during the updates (writes to
per-CPU refcounts) to safe-guard against races with interrupt handlers.
Beyond that, we can keep the interrupts enabled and still be safe w.r.t
interrupt handlers that can act as readers.
Basically the idea is that we differentiate between the *part* of the
per-CPU refcount that we use for reference counting vs the part that we use
merely to make the writer wait for us to switch over to the right
synchronization scheme.
The scheme involves splitting the per-CPU refcounts into 2 parts:
eg: the lower 16 bits are used to track the nesting depth of the reader
(a "nested-counter"), and the remaining (upper) bits are used to merely mark
the presence of the reader.
As long as the overall reader_refcnt is non-zero, the writer waits for the
reader (assuming that the reader is still actively using per-CPU refcounts for
synchronization).
The reader first sets one of the higher bits to mark its presence, and then
uses the lower 16 bits to manage the nesting depth. So, an interrupt handler
coming in as illustrated above will be able to distinguish between "this is
a nested read-side critical section" vs "we have merely marked our presence
to make the writer wait for us to switch" by looking at the same refcount.
Thus, it makes it unnecessary to keep interrupts disabled throughout the
read-side critical section, despite having the possibility of interrupt
handlers being readers themselves.
Implement this logic and rename the locking functions appropriately, to
reflect what they do.
Based-on-idea-by: Oleg Nesterov [off-list ref]
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
include/linux/percpu-rwlock.h | 10 ++++---
lib/percpu-rwlock.c | 57 ++++++++++++++++++++++++++---------------
2 files changed, 42 insertions(+), 25 deletions(-)
@@ -95,9 +103,19 @@ void percpu_read_lock(struct percpu_rwlock *pcpu_rwlock)smp_mb();if(likely(!writer_active(pcpu_rwlock))){-gotoout;+this_cpu_inc(pcpu_rwlock->rw_state->reader_refcnt);}else{/* Writer is active, so switch to global rwlock. */++/*+*Whilewearespinningon->global_rwlock,an+*interruptcanhitus,andtheinterrupthandler+*mightcallthisfunction.Thedistinctionbetween+*READER_PRESENTandtherefcnthelpsensurethatthe+*interrupthandleralsotakesthisbranchandspins+*onthe->global_rwlock,aslongasthewriteris+*active.+*/read_lock(&pcpu_rwlock->global_rwlock);/*
@@ -107,29 +125,24 @@ void percpu_read_lock(struct percpu_rwlock *pcpu_rwlock)*refcounts.(Thisalsohelpsavoidheterogeneousnestingof*readers).*/-if(writer_active(pcpu_rwlock)){-/*-*Theabovewriter_active()checkcangetreordered-*withthis_cpu_dec()below,butthisisOK,because-*holdingtherwlockisconservative.-*/-this_cpu_dec(pcpu_rwlock->rw_state->reader_refcnt);-}else{+if(!writer_active(pcpu_rwlock)){+this_cpu_inc(pcpu_rwlock->rw_state->reader_refcnt);read_unlock(&pcpu_rwlock->global_rwlock);}}-out:+this_cpu_sub(pcpu_rwlock->rw_state->reader_refcnt,READER_PRESENT);+/* Prevent reordering of any subsequent reads/writes */smp_mb();}-voidpercpu_read_unlock(structpercpu_rwlock*pcpu_rwlock)+voidpercpu_read_unlock_irqsafe(structpercpu_rwlock*pcpu_rwlock){/**Weneverallowheterogeneousnestingofreaders.Soitistrivial*tofindoutthekindofreaderweare,andundotheoperation-*donebyourcorrespondingpercpu_read_lock().+*donebyourcorrespondingpercpu_read_lock_irqsafe().*//* Try to fast-path: a nested percpu reader is the simplest case */
On Mon, Feb 18, 2013 at 06:12:54PM +0530, Srivatsa S. Bhat wrote:
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Mikael Starvik <redacted>
Cc: linux-cris-kernel@axis.com
Signed-off-by: Srivatsa S. Bhat <redacted>
From: Michel Lespinasse <hidden> Date: 2013-02-18 15:45:33
Hi Srivasta,
I admit not having followed in detail the threads about the previous
iteration, so some of my comments may have been discussed already
before - apologies if that is the case.
On Mon, Feb 18, 2013 at 8:38 PM, Srivatsa S. Bhat
[off-list ref] wrote:
Reader-writer locks and per-cpu counters are recursive, so they can be
used in a nested fashion in the reader-path, which makes per-CPU rwlocks also
recursive. Also, this design of switching the synchronization scheme ensures
that you can safely nest and use these locks in a very flexible manner.
I like the general idea of switching between per-cpu and global
rwlocks as needed; however I dislike unfair locks, and especially
unfair recursive rwlocks.
If you look at rwlock_t, the main reason we haven't been able to
implement reader/writer fairness there is because tasklist_lock makes
use of the recursive nature of the rwlock_t read side. I'm worried
about introducing more lock usages that would make use of the same
property for your proposed lock.
I am fine with your proposal not implementing reader/writer fairness
from day 1, but I am worried about your proposal having a recursive
reader side. Or, to put it another way: if your proposal didn't have a
recursive reader side, and rwlock_t could somehow be changed to
implement reader/writer fairness, then this property could
automatically propagate into your proposed rwlock; but if anyone makes
use of the recursive nature of your proposal then implementing
reader/writer fairness later won't be as easy.
I see that the very next change in this series is talking about
acquiring the read side from interrupts, so it does look like you're
planning to make use of the recursive nature of the read side. I kinda
wish you didn't, as this is exactly replicating the design of
tasklist_lock which is IMO problematic. Your prior proposal of
disabling interrupts during the read side had other disadvantages, but
I think it was nice that it didn't rely on having a recursive read
side.
I'm personally not a fan of such one-line shorthand functions - I
think they tend to make the code harder to read instead of easier, as
one constantly has to refer to them to understand what's actually
going on.
void percpu_write_lock(struct percpu_rwlock *pcpu_rwlock)
{
+ unsigned int cpu;
+
+ /*
+ * Tell all readers that a writer is becoming active, so that they
+ * start switching over to the global rwlock.
+ */
+ for_each_possible_cpu(cpu)
+ per_cpu_ptr(pcpu_rwlock->rw_state, cpu)->writer_signal = true;
I don't see anything preventing a race with the corresponding code in
percpu_write_unlock() that sets writer_signal back to false. Did I
miss something here ? It seems to me we don't have any guarantee that
all writer signals will be set to true at the end of the loop...
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Michel Lespinasse <hidden> Date: 2013-02-18 15:51:45
On Mon, Feb 18, 2013 at 8:39 PM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted hunk
@@ -200,6 +217,16 @@ void percpu_write_lock_irqsave(struct percpu_rwlock *pcpu_rwlock, smp_mb(); /* Complete the wait-for-readers, before taking the lock */ write_lock_irqsave(&pcpu_rwlock->global_rwlock, *flags);++ /*+ * It is desirable to allow the writer to acquire the percpu-rwlock+ * for read (if necessary), without deadlocking or getting complaints+ * from lockdep. To achieve that, just increment the reader_refcnt of+ * this CPU - that way, any attempt by the writer to acquire the+ * percpu-rwlock for read, will get treated as a case of nested percpu+ * reader, which is safe, from a locking perspective.+ */+ this_cpu_inc(pcpu_rwlock->rw_state->reader_refcnt);
I find this quite disgusting, but once again this may be because I
don't like unfair recursive rwlocks.
In my opinion, the alternative of explicitly not taking the read lock
when one already has the write lock sounds *much* nicer.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 16:24:00
Hi Michel,
On 02/18/2013 09:15 PM, Michel Lespinasse wrote:
Hi Srivasta,
I admit not having followed in detail the threads about the previous
iteration, so some of my comments may have been discussed already
before - apologies if that is the case.
On Mon, Feb 18, 2013 at 8:38 PM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
Reader-writer locks and per-cpu counters are recursive, so they can be
used in a nested fashion in the reader-path, which makes per-CPU rwlocks also
recursive. Also, this design of switching the synchronization scheme ensures
that you can safely nest and use these locks in a very flexible manner.
I like the general idea of switching between per-cpu and global
rwlocks as needed; however I dislike unfair locks, and especially
unfair recursive rwlocks.
If you look at rwlock_t, the main reason we haven't been able to
implement reader/writer fairness there is because tasklist_lock makes
use of the recursive nature of the rwlock_t read side. I'm worried
about introducing more lock usages that would make use of the same
property for your proposed lock.
I am fine with your proposal not implementing reader/writer fairness
from day 1, but I am worried about your proposal having a recursive
reader side. Or, to put it another way: if your proposal didn't have a
recursive reader side, and rwlock_t could somehow be changed to
implement reader/writer fairness, then this property could
automatically propagate into your proposed rwlock; but if anyone makes
use of the recursive nature of your proposal then implementing
reader/writer fairness later won't be as easy.
Actually, we don't want reader/writer fairness in this particular case.
We want deadlock safety - and in this particular case, this is guaranteed
by the unfair nature of rwlocks today.
I understand that you want to make rwlocks fair. So, I am thinking of
going ahead with Tejun's proposal - implementing our own unfair locking
scheme inside percpu-rwlocks using atomic ops or something like that, and
being completely independent of rwlock_t. That way, you can easily go
ahead with making rwlocks fair without fear of breaking CPU hotplug.
However I would much prefer making that change to percpu-rwlocks as a
separate patchset, after this patchset goes in, so that we can also see
how well this unfair logic performs in practice.
And regarding recursive reader side,... the way I see it, having a
recursive reader side is a primary requirement in this case. The reason is
that the existing reader side (with stop_machine) uses preempt_disable(),
which is recursive. So our replacement also has to be recursive.
I see that the very next change in this series is talking about
acquiring the read side from interrupts, so it does look like you're
planning to make use of the recursive nature of the read side.
Yes.. I don't think we can avoid that. Moreover, since we _want_ unfair
reader/writer semantics to allow flexible locking rules and guarantee
deadlock-safety, having a recursive reader side is not even an issue, IMHO.
I kinda
wish you didn't, as this is exactly replicating the design of
tasklist_lock which is IMO problematic. Your prior proposal of
disabling interrupts during the read side had other disadvantages, but
I think it was nice that it didn't rely on having a recursive read
side.
We can have readers from non-interrupt contexts too, which depend on the
recursive property...
I'm personally not a fan of such one-line shorthand functions - I
think they tend to make the code harder to read instead of easier, as
one constantly has to refer to them to understand what's actually
going on.
I got rid of most of the helper functions in this version. But I would rather
prefer retaining the above ones, because they are unwieldy and long. And IMHO
the short-hand names are pretty descriptive, so you might not actually need
to keep referring to their implementations all the time.
quoted
void percpu_write_lock(struct percpu_rwlock *pcpu_rwlock)
{
+ unsigned int cpu;
+
+ /*
+ * Tell all readers that a writer is becoming active, so that they
+ * start switching over to the global rwlock.
+ */
+ for_each_possible_cpu(cpu)
+ per_cpu_ptr(pcpu_rwlock->rw_state, cpu)->writer_signal = true;
I don't see anything preventing a race with the corresponding code in
percpu_write_unlock() that sets writer_signal back to false. Did I
miss something here ? It seems to me we don't have any guarantee that
all writer signals will be set to true at the end of the loop...
Ah, thanks for pointing that out! IIRC Oleg had pointed this issue in the last
version, but back then, I hadn't fully understood what he meant. Your
explanation made it clear. I'll work on fixing this.
Thanks a lot for your review Michel!
Regards,
Srivatsa S. Bhat
From: Michel Lespinasse <hidden> Date: 2013-02-18 16:24:28
On Mon, Feb 18, 2013 at 8:39 PM, Srivatsa S. Bhat
[off-list ref] wrote:
Some important design requirements and considerations:
-----------------------------------------------------
1. Scalable synchronization at the reader-side, especially in the fast-path
Any synchronization at the atomic hotplug readers side must be highly
scalable - avoid global single-holder locks/counters etc. Because, these
paths currently use the extremely fast preempt_disable(); our replacement
to preempt_disable() should not become ridiculously costly and also should
not serialize the readers among themselves needlessly.
At a minimum, the new APIs must be extremely fast at the reader side
atleast in the fast-path, when no CPU offline writers are active.
2. preempt_disable() was recursive. The replacement should also be recursive.
3. No (new) lock-ordering restrictions
preempt_disable() was super-flexible. It didn't impose any ordering
restrictions or rules for nesting. Our replacement should also be equally
flexible and usable.
4. No deadlock possibilities
Regular per-cpu locking is not the way to go if we want to have relaxed
rules for lock-ordering. Because, we can end up in circular-locking
dependencies as explained in https://lkml.org/lkml/2012/12/6/290
So, avoid the usual per-cpu locking schemes (per-cpu locks/per-cpu atomic
counters with spin-on-contention etc) as much as possible, to avoid
numerous deadlock possibilities from creeping in.
Implementation of the design:
----------------------------
We use per-CPU reader-writer locks for synchronization because:
a. They are quite fast and scalable in the fast-path (when no writers are
active), since they use fast per-cpu counters in those paths.
b. They are recursive at the reader side.
c. They provide a good amount of safety against deadlocks; they don't
spring new deadlock possibilities on us from out of nowhere. As a
result, they have relaxed locking rules and are quite flexible, and
thus are best suited for replacing usages of preempt_disable() or
local_irq_disable() at the reader side.
Together, these satisfy all the requirements mentioned above.
Thanks for this detailed design explanation.
+/*
+ * Invoked by atomic hotplug reader (a task which wants to prevent
+ * CPU offline, but which can't afford to sleep), to prevent CPUs from
+ * going offline. So, you can call this function from atomic contexts
+ * (including interrupt handlers).
+ *
+ * Note: This does NOT prevent CPUs from coming online! It only prevents
+ * CPUs from going offline.
+ *
+ * You can call this function recursively.
+ *
+ * Returns with preemption disabled (but interrupts remain as they are;
+ * they are not disabled).
+ */
+void get_online_cpus_atomic(void)
+{
+ percpu_read_lock_irqsafe(&hotplug_pcpu_rwlock);
+}
+EXPORT_SYMBOL_GPL(get_online_cpus_atomic);
+
+void put_online_cpus_atomic(void)
+{
+ percpu_read_unlock_irqsafe(&hotplug_pcpu_rwlock);
+}
+EXPORT_SYMBOL_GPL(put_online_cpus_atomic);
So, you made it clear why you want a recursive read side here.
I am wondering though, if you could take care of recursive uses in
get/put_online_cpus_atomic() instead of doing it as a property of your
rwlock:
get_online_cpus_atomic()
{
unsigned long flags;
local_irq_save(flags);
if (this_cpu_inc_return(hotplug_recusion_count) == 1)
percpu_read_lock_irqsafe(&hotplug_pcpu_rwlock);
local_irq_restore(flags);
}
Once again, the idea there is to avoid baking the reader side
recursive properties into your rwlock itself, so that it won't be
impossible to implement reader/writer fairness into your rwlock in the
future (which may be not be very important for the hotplug use, but
could be when other uses get introduced).
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Steven Rostedt <rostedt@goodmis.org> Date: 2013-02-18 16:31:33
On Mon, 2013-02-18 at 21:51 +0530, Srivatsa S. Bhat wrote:
Hi Michel,
Yes.. I don't think we can avoid that. Moreover, since we _want_ unfair
reader/writer semantics to allow flexible locking rules and guarantee
deadlock-safety, having a recursive reader side is not even an issue, IMHO.
Recursive unfair reader lock may guarantee deadlock-safety, but
remember, it adds a higher probability of live-locking the write_lock.
Which is another argument to keep this separate to cpu hotplug only.
-- Steve
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 16:33:42
On 02/18/2013 09:21 PM, Michel Lespinasse wrote:
On Mon, Feb 18, 2013 at 8:39 PM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
@@ -200,6 +217,16 @@ void percpu_write_lock_irqsave(struct percpu_rwlock *pcpu_rwlock, smp_mb(); /* Complete the wait-for-readers, before taking the lock */ write_lock_irqsave(&pcpu_rwlock->global_rwlock, *flags);++ /*+ * It is desirable to allow the writer to acquire the percpu-rwlock+ * for read (if necessary), without deadlocking or getting complaints+ * from lockdep. To achieve that, just increment the reader_refcnt of+ * this CPU - that way, any attempt by the writer to acquire the+ * percpu-rwlock for read, will get treated as a case of nested percpu+ * reader, which is safe, from a locking perspective.+ */+ this_cpu_inc(pcpu_rwlock->rw_state->reader_refcnt);
I find this quite disgusting, but once again this may be because I
don't like unfair recursive rwlocks.
:-)
In my opinion, the alternative of explicitly not taking the read lock
when one already has the write lock sounds *much* nicer.
I don't seem to recall any strong reasons to do it this way, so I don't have
any strong opinions on doing it this way. But one of the things to note is that,
in the CPU Hotplug case, the readers are *way* more hotter than the writer.
So avoiding extra checks/'if' conditions/memory barriers in the reader-side
is very welcome. (If we slow down the read-side, we get a performance hit
even when *not* doing hotplug!). Considering this, the logic used in this
patchset seems better, IMHO.
Regards,
Srivatsa S. Bhat
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 16:45:44
On 02/18/2013 09:53 PM, Michel Lespinasse wrote:
On Mon, Feb 18, 2013 at 8:39 PM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
Some important design requirements and considerations:
-----------------------------------------------------
[...]
quoted
+/*
+ * Invoked by atomic hotplug reader (a task which wants to prevent
+ * CPU offline, but which can't afford to sleep), to prevent CPUs from
+ * going offline. So, you can call this function from atomic contexts
+ * (including interrupt handlers).
+ *
+ * Note: This does NOT prevent CPUs from coming online! It only prevents
+ * CPUs from going offline.
+ *
+ * You can call this function recursively.
+ *
+ * Returns with preemption disabled (but interrupts remain as they are;
+ * they are not disabled).
+ */
+void get_online_cpus_atomic(void)
+{
+ percpu_read_lock_irqsafe(&hotplug_pcpu_rwlock);
+}
+EXPORT_SYMBOL_GPL(get_online_cpus_atomic);
+
+void put_online_cpus_atomic(void)
+{
+ percpu_read_unlock_irqsafe(&hotplug_pcpu_rwlock);
+}
+EXPORT_SYMBOL_GPL(put_online_cpus_atomic);
So, you made it clear why you want a recursive read side here.
I am wondering though, if you could take care of recursive uses in
get/put_online_cpus_atomic() instead of doing it as a property of your
rwlock:
get_online_cpus_atomic()
{
unsigned long flags;
local_irq_save(flags);
if (this_cpu_inc_return(hotplug_recusion_count) == 1)
percpu_read_lock_irqsafe(&hotplug_pcpu_rwlock);
local_irq_restore(flags);
}
Once again, the idea there is to avoid baking the reader side
recursive properties into your rwlock itself, so that it won't be
impossible to implement reader/writer fairness into your rwlock in the
future (which may be not be very important for the hotplug use, but
could be when other uses get introduced).
Hmm, your proposal above looks good to me, at first glance.
(Sorry, I had mistaken your earlier mails to mean that you were against
recursive reader-side, while you actually meant that you didn't like
implementing the recursive reader-side logic using the recursive property
of rwlocks).
While your idea above looks good, it might introduce more complexity
in the unlock path, since this would allow nesting of heterogeneous readers
(ie., if hotplug_recursion_count == 1, you don't know whether you need to
simply decrement the counter or unlock the rwlock as well).
But I'll give this some more thought to see if we can implement this
without making it too complex. Thank you!
Regards,
Srivatsa S. Bhat
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 16:48:16
On 02/18/2013 10:01 PM, Steven Rostedt wrote:
On Mon, 2013-02-18 at 21:51 +0530, Srivatsa S. Bhat wrote:
quoted
Hi Michel,
quoted
Yes.. I don't think we can avoid that. Moreover, since we _want_ unfair
reader/writer semantics to allow flexible locking rules and guarantee
deadlock-safety, having a recursive reader side is not even an issue, IMHO.
Recursive unfair reader lock may guarantee deadlock-safety, but
remember, it adds a higher probability of live-locking the write_lock.
Which is another argument to keep this separate to cpu hotplug only.
From: Michel Lespinasse <hidden> Date: 2013-02-18 17:21:09
On Tue, Feb 19, 2013 at 12:43 AM, Srivatsa S. Bhat
[off-list ref] wrote:
On 02/18/2013 09:53 PM, Michel Lespinasse wrote:
quoted
I am wondering though, if you could take care of recursive uses in
get/put_online_cpus_atomic() instead of doing it as a property of your
rwlock:
get_online_cpus_atomic()
{
unsigned long flags;
local_irq_save(flags);
if (this_cpu_inc_return(hotplug_recusion_count) == 1)
percpu_read_lock_irqsafe(&hotplug_pcpu_rwlock);
local_irq_restore(flags);
}
Once again, the idea there is to avoid baking the reader side
recursive properties into your rwlock itself, so that it won't be
impossible to implement reader/writer fairness into your rwlock in the
future (which may be not be very important for the hotplug use, but
could be when other uses get introduced).
Hmm, your proposal above looks good to me, at first glance.
(Sorry, I had mistaken your earlier mails to mean that you were against
recursive reader-side, while you actually meant that you didn't like
implementing the recursive reader-side logic using the recursive property
of rwlocks).
To be honest, I was replying as I went through the series, so I hadn't
digested your hotplug use case yet :)
But yes - I don't like having the rwlock itself be recursive, but I do
understand that you have a legitimate requirement for
get_online_cpus_atomic() to be recursive. This IMO points to the
direction I suggested, of explicitly handling the recusion in
get_online_cpus_atomic() so that the underlying rwlock doesn't have to
support recursive reader side itself.
(And this would work for the idea of making writers own the reader
side as well - you can do it with the hotplug_recursion_count instead
of with the underlying rwlock).
While your idea above looks good, it might introduce more complexity
in the unlock path, since this would allow nesting of heterogeneous readers
(ie., if hotplug_recursion_count == 1, you don't know whether you need to
simply decrement the counter or unlock the rwlock as well).
Well, I think the idea doesn't make the underlying rwlock more
complex, since you could in principle keep your existing
percpu_read_lock_irqsafe implementation as is and just remove the
recursive behavior from its documentation.
Now ideally if we're adding a bit of complexity in
get_online_cpus_atomic() it'd be nice if we could remove some from
percpu_read_lock_irqsafe, but I haven't thought about that deeply
either. I think you'd still want to have the equivalent of a percpu
reader_refcnt, except it could now be a bool instead of an int, and
percpu_read_lock_irqsafe would still set it to back to 0/false after
acquiring the global read side if a writer is signaled. Basically your
existing percpu_read_lock_irqsafe code should still work, and we could
remove just the parts that were only there to deal with the recursive
property.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 17:58:34
On 02/18/2013 09:51 PM, Srivatsa S. Bhat wrote:
Hi Michel,
On 02/18/2013 09:15 PM, Michel Lespinasse wrote:
quoted
Hi Srivasta,
I admit not having followed in detail the threads about the previous
iteration, so some of my comments may have been discussed already
before - apologies if that is the case.
On Mon, Feb 18, 2013 at 8:38 PM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
Reader-writer locks and per-cpu counters are recursive, so they can be
used in a nested fashion in the reader-path, which makes per-CPU rwlocks also
recursive. Also, this design of switching the synchronization scheme ensures
that you can safely nest and use these locks in a very flexible manner.
[...]
quoted
quoted
void percpu_write_lock(struct percpu_rwlock *pcpu_rwlock)
{
+ unsigned int cpu;
+
+ /*
+ * Tell all readers that a writer is becoming active, so that they
+ * start switching over to the global rwlock.
+ */
+ for_each_possible_cpu(cpu)
+ per_cpu_ptr(pcpu_rwlock->rw_state, cpu)->writer_signal = true;
I don't see anything preventing a race with the corresponding code in
percpu_write_unlock() that sets writer_signal back to false. Did I
miss something here ? It seems to me we don't have any guarantee that
all writer signals will be set to true at the end of the loop...
Ah, thanks for pointing that out! IIRC Oleg had pointed this issue in the last
version, but back then, I hadn't fully understood what he meant. Your
explanation made it clear. I'll work on fixing this.
We can fix this by using the simple patch (untested) shown below.
The alternative would be to acquire the rwlock for write, update the
->writer_signal values, release the lock, wait for readers to switch,
again acquire the rwlock for write with interrupts disabled etc... which
makes it kinda messy, IMHO. So I prefer the simple version shown below.
From: Michel Lespinasse <hidden> Date: 2013-02-18 18:07:50
On Tue, Feb 19, 2013 at 1:56 AM, Srivatsa S. Bhat
[off-list ref] wrote:
On 02/18/2013 09:51 PM, Srivatsa S. Bhat wrote:
quoted
On 02/18/2013 09:15 PM, Michel Lespinasse wrote:
quoted
I don't see anything preventing a race with the corresponding code in
percpu_write_unlock() that sets writer_signal back to false. Did I
miss something here ? It seems to me we don't have any guarantee that
all writer signals will be set to true at the end of the loop...
Ah, thanks for pointing that out! IIRC Oleg had pointed this issue in the last
version, but back then, I hadn't fully understood what he meant. Your
explanation made it clear. I'll work on fixing this.
We can fix this by using the simple patch (untested) shown below.
The alternative would be to acquire the rwlock for write, update the
->writer_signal values, release the lock, wait for readers to switch,
again acquire the rwlock for write with interrupts disabled etc... which
makes it kinda messy, IMHO. So I prefer the simple version shown below.
Looks good.
Another alternative would be to make writer_signal an atomic integer
instead of a bool. That way writers can increment it before locking
and decrement it while unlocking.
To reduce the number of atomic ops during writer lock/unlock, the
writer_signal could also be a global read_mostly variable (I don't see
any downsides to that compared to having it percpu - or is it because
you wanted all the fastpath state to be in one single cacheline ?)
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 18:16:55
On 02/18/2013 11:37 PM, Michel Lespinasse wrote:
On Tue, Feb 19, 2013 at 1:56 AM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
On 02/18/2013 09:51 PM, Srivatsa S. Bhat wrote:
quoted
On 02/18/2013 09:15 PM, Michel Lespinasse wrote:
quoted
I don't see anything preventing a race with the corresponding code in
percpu_write_unlock() that sets writer_signal back to false. Did I
miss something here ? It seems to me we don't have any guarantee that
all writer signals will be set to true at the end of the loop...
Ah, thanks for pointing that out! IIRC Oleg had pointed this issue in the last
version, but back then, I hadn't fully understood what he meant. Your
explanation made it clear. I'll work on fixing this.
We can fix this by using the simple patch (untested) shown below.
The alternative would be to acquire the rwlock for write, update the
->writer_signal values, release the lock, wait for readers to switch,
again acquire the rwlock for write with interrupts disabled etc... which
makes it kinda messy, IMHO. So I prefer the simple version shown below.
Looks good.
Another alternative would be to make writer_signal an atomic integer
instead of a bool. That way writers can increment it before locking
and decrement it while unlocking.
Yep, that would also do. But the spinlock version looks simpler - no need
to check if the atomic counter is non-zero, no need to explicitly spin in
a tight-loop etc.
To reduce the number of atomic ops during writer lock/unlock, the
writer_signal could also be a global read_mostly variable (I don't see
any downsides to that compared to having it percpu - or is it because
you wanted all the fastpath state to be in one single cacheline ?)
Yes, we (Oleg and I) debated for a while about global vs percpu, and then
finally decided to go with percpu to have cache benefits.
Regards,
Srivatsa S. Bhat
From: Srivatsa S. Bhat <hidden> Date: 2013-02-18 18:53:07
On 02/18/2013 10:51 PM, Michel Lespinasse wrote:
On Tue, Feb 19, 2013 at 12:43 AM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
On 02/18/2013 09:53 PM, Michel Lespinasse wrote:
quoted
I am wondering though, if you could take care of recursive uses in
get/put_online_cpus_atomic() instead of doing it as a property of your
rwlock:
get_online_cpus_atomic()
{
unsigned long flags;
local_irq_save(flags);
if (this_cpu_inc_return(hotplug_recusion_count) == 1)
percpu_read_lock_irqsafe(&hotplug_pcpu_rwlock);
local_irq_restore(flags);
}
Once again, the idea there is to avoid baking the reader side
recursive properties into your rwlock itself, so that it won't be
impossible to implement reader/writer fairness into your rwlock in the
future (which may be not be very important for the hotplug use, but
could be when other uses get introduced).
Hmm, your proposal above looks good to me, at first glance.
(Sorry, I had mistaken your earlier mails to mean that you were against
recursive reader-side, while you actually meant that you didn't like
implementing the recursive reader-side logic using the recursive property
of rwlocks).
To be honest, I was replying as I went through the series, so I hadn't
digested your hotplug use case yet :)
But yes - I don't like having the rwlock itself be recursive, but I do
understand that you have a legitimate requirement for
get_online_cpus_atomic() to be recursive. This IMO points to the
direction I suggested, of explicitly handling the recusion in
get_online_cpus_atomic() so that the underlying rwlock doesn't have to
support recursive reader side itself.
(And this would work for the idea of making writers own the reader
side as well - you can do it with the hotplug_recursion_count instead
of with the underlying rwlock).
quoted
While your idea above looks good, it might introduce more complexity
in the unlock path, since this would allow nesting of heterogeneous readers
(ie., if hotplug_recursion_count == 1, you don't know whether you need to
simply decrement the counter or unlock the rwlock as well).
Well, I think the idea doesn't make the underlying rwlock more
complex, since you could in principle keep your existing
percpu_read_lock_irqsafe implementation as is and just remove the
recursive behavior from its documentation.
Now ideally if we're adding a bit of complexity in
get_online_cpus_atomic() it'd be nice if we could remove some from
percpu_read_lock_irqsafe, but I haven't thought about that deeply
either. I think you'd still want to have the equivalent of a percpu
reader_refcnt, except it could now be a bool instead of an int, and
percpu_read_lock_irqsafe would still set it to back to 0/false after
acquiring the global read side if a writer is signaled. Basically your
existing percpu_read_lock_irqsafe code should still work, and we could
remove just the parts that were only there to deal with the recursive
property.
But, the whole intention behind removing the parts depending on the
recursive property of rwlocks would be to make it easier to make rwlocks
fair (going forward) right? Then, that won't work for CPU hotplug, because,
just like we have a legitimate reason to have recursive
get_online_cpus_atomic(), we also have a legitimate reason to have
unfairness in locking (i.e., for deadlock-safety). So we simply can't
afford to make the locking fair - we'll end up in too many deadlock
possibilities, as hinted in the changelog of patch 1.
(Remember, we are replacing preempt_disable(), which had absolutely no
special nesting rules or locking implications. That is why we are forced
to provide maximum locking flexibility and safety against new/previously
non-existent deadlocks, in the new synchronization scheme).
So the only long-term solution I can think of is to decouple
percpu-rwlocks and rwlock_t (like what Tejun suggested) by implementing
our own unfair locking scheme inside. What do you think?
Regards,
Srivatsa S. Bhat
From: Michel Lespinasse <hidden> Date: 2013-02-19 09:40:55
On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat
[off-list ref] wrote:
But, the whole intention behind removing the parts depending on the
recursive property of rwlocks would be to make it easier to make rwlocks
fair (going forward) right? Then, that won't work for CPU hotplug, because,
just like we have a legitimate reason to have recursive
get_online_cpus_atomic(), we also have a legitimate reason to have
unfairness in locking (i.e., for deadlock-safety). So we simply can't
afford to make the locking fair - we'll end up in too many deadlock
possibilities, as hinted in the changelog of patch 1.
Grumpf - I hadn't realized that making the underlying rwlock fair
would break your hotplug use case. But you are right, it would. Oh
well :/
So the only long-term solution I can think of is to decouple
percpu-rwlocks and rwlock_t (like what Tejun suggested) by implementing
our own unfair locking scheme inside. What do you think?
I have no idea how hard would it be to change get_online_cpus_atomic()
call sites so that the hotplug rwlock read side has a defined order vs
other locks (thus making sure the situation you describe in patch 1
doesn't happen). I agree we shouldn't base our short term plans around
that, but maybe that's doable in the long term ???
Otherwise, I think we should add some big-fat-warning that percpu
rwlocks don't have reader/writer fairness, that the hotplug use case
actually depends on the unfairness / would break if the rwlock was
made fair, and that any new uses of percpu rwlocks should be very
carefully considered because of the reader/writer fairness issues.
Maybe even give percpu rwlocks a less generic sounding name, given how
constrained they are by the hotplug use case.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
From: Srivatsa S. Bhat <hidden> Date: 2013-02-19 09:58:09
On 02/19/2013 03:10 PM, Michel Lespinasse wrote:
On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
But, the whole intention behind removing the parts depending on the
recursive property of rwlocks would be to make it easier to make rwlocks
fair (going forward) right? Then, that won't work for CPU hotplug, because,
just like we have a legitimate reason to have recursive
get_online_cpus_atomic(), we also have a legitimate reason to have
unfairness in locking (i.e., for deadlock-safety). So we simply can't
afford to make the locking fair - we'll end up in too many deadlock
possibilities, as hinted in the changelog of patch 1.
Grumpf - I hadn't realized that making the underlying rwlock fair
would break your hotplug use case. But you are right, it would. Oh
well :/
Yeah :-/
quoted
So the only long-term solution I can think of is to decouple
percpu-rwlocks and rwlock_t (like what Tejun suggested) by implementing
our own unfair locking scheme inside. What do you think?
I have no idea how hard would it be to change get_online_cpus_atomic()
call sites so that the hotplug rwlock read side has a defined order vs
other locks (thus making sure the situation you describe in patch 1
doesn't happen). I agree we shouldn't base our short term plans around
that, but maybe that's doable in the long term ???
I think it should be possible in the longer term. I'm expecting it to be
*much much* harder to audit and convert (requiring a lot of subsystem
knowledge of each subsystem that we are touching), than the simpler
tree-wide conversion that I did in this patchset... but I don't think it
is impossible.
Otherwise, I think we should add some big-fat-warning that percpu
rwlocks don't have reader/writer fairness, that the hotplug use case
actually depends on the unfairness / would break if the rwlock was
made fair, and that any new uses of percpu rwlocks should be very
carefully considered because of the reader/writer fairness issues.
In fact, when I started out, I actually contained all the new locking code
inside CPU hotplug itself, and didn't even expose it as a generic percpu
rwlock in some of the previous versions of this patchset... :-)
But now that we already have a generic locking scheme exposed, we could
add a warning against using it without due consideration.
Maybe even give percpu rwlocks a less generic sounding name, given how
constrained they are by the hotplug use case.
I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
IMHO, the warning/documentation should suffice for anybody wanting to
try out this locking scheme for other use-cases.
Regards,
Srivatsa S. Bhat
From: David Laight <hidden> Date: 2013-02-19 10:43:59
I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
IMHO, the warning/documentation should suffice for anybody wanting to
try out this locking scheme for other use-cases.
I presume that by 'fairness' you mean 'write preference'?
I'd not sure how difficult it would be, but maybe have two functions
for acquiring the lock for read, one blocks if there is a writer
waiting, the other doesn't.
That way you can change the individual call sites separately.
The other place I can imagine a per-cpu rwlock being used
is to allow a driver to disable 'sleep' or software controlled
hardware removal while it performs a sequence of operations.
David
From: Srivatsa S. Bhat <hidden> Date: 2013-02-19 11:00:55
On 02/19/2013 04:12 PM, David Laight wrote:
quoted
I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
IMHO, the warning/documentation should suffice for anybody wanting to
try out this locking scheme for other use-cases.
I presume that by 'fairness' you mean 'write preference'?
Yep.
I'd not sure how difficult it would be, but maybe have two functions
for acquiring the lock for read, one blocks if there is a writer
waiting, the other doesn't.
That way you can change the individual call sites separately.
Right, we could probably use that method to change the call sites in
multiple stages, in the future.
The other place I can imagine a per-cpu rwlock being used
is to allow a driver to disable 'sleep' or software controlled
hardware removal while it performs a sequence of operations.
BTW, per-cpu rwlocks use spinlocks underneath, so they can be used only
in atomic contexts (you can't sleep holding this lock). So that would
probably make it less attractive or useless to "heavy-weight" usecases
like the latter one you mentioned. They probably need to use per-cpu
rw-semaphore or some such, which allows sleeping. I'm not very certain
of the exact usecases you are talking about, but I just wanted to
point out that percpu-rwlocks might not be applicable to many scenarios.
..(which might be a good thing, considering its unfair property today).
Regards,
Srivatsa S. Bhat
From: Lai Jiangshan <hidden> Date: 2013-02-25 15:53:28
Hi, Srivatsa,
The target of the whole patchset is nice for me.
A question: How did you find out the such usages of
"preempt_disable()" and convert them? did all are converted?
And I think the lock is too complex and reinvent the wheel, why don't
you reuse the lglock?
I wrote an untested draft here.
Thanks,
Lai
PS: Some HA tools(I'm writing one) which takes checkpoints of
virtual-machines frequently, I guess this patchset can speedup the
tools.
From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <redacted>
Date: Mon, 25 Feb 2013 23:14:27 +0800
Subject: [PATCH] lglock: add read-preference local-global rwlock
locality via lglock(trylock)
read-preference read-write-lock via fallback rwlock_t
Signed-off-by: Lai Jiangshan <redacted>
---
include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
From: Srivatsa S. Bhat <hidden> Date: 2013-02-25 19:28:41
Hi Lai,
On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
Hi, Srivatsa,
The target of the whole patchset is nice for me.
Cool! Thanks :-)
A question: How did you find out the such usages of
"preempt_disable()" and convert them? did all are converted?
Well, I scanned through the source tree for usages which implicitly
disabled CPU offline and converted them over. Its not limited to uses
of preempt_disable() alone - even spin_locks, rwlocks, local_irq_disable()
etc also help disable CPU offline. So I tried to dig out all such uses
and converted them. However, since the merge window is open, a lot of
new code is flowing into the tree. So I'll have to rescan the tree to
see if there are any more places to convert.
And I think the lock is too complex and reinvent the wheel, why don't
you reuse the lglock?
lglocks? No way! ;-) See below...
quoted hunk
I wrote an untested draft here.
Thanks,
Lai
PS: Some HA tools(I'm writing one) which takes checkpoints of
virtual-machines frequently, I guess this patchset can speedup the
tools.
From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <redacted>
Date: Mon, 25 Feb 2013 23:14:27 +0800
Subject: [PATCH] lglock: add read-preference local-global rwlock
locality via lglock(trylock)
read-preference read-write-lock via fallback rwlock_t
Signed-off-by: Lai Jiangshan <redacted>
---
include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
If I read the code above correctly, all you are doing is implementing a
recursive reader-side primitive (ie., allowing the reader to call these
functions recursively, without resulting in a self-deadlock).
But the thing is, making the reader-side recursive is the least of our
problems! Our main challenge is to make the locking extremely flexible
and also safe-guard it against circular-locking-dependencies and deadlocks.
Please take a look at the changelog of patch 1 - it explains the situation
with an example.
This does a for-loop on all CPUs and takes their locks one-by-one. That's
exactly what we want to prevent, because that is the _source_ of all our
deadlock woes in this case. In the presence of perfect lock ordering
guarantees, this wouldn't have been a problem (that's why lglocks are
being used successfully elsewhere in the kernel). In the stop-machine()
removal case, the over-flexibility of preempt_disable() forces us to provide
an equally flexible locking alternative. Hence we can't use such per-cpu
locking schemes.
You might note that, for exactly this reason, I haven't actually used any
per-cpu _locks_ in this synchronization scheme, though it is named as
"per-cpu rwlocks". The only per-cpu component here are the refcounts, and
we consciously avoid waiting/spinning on them (because then that would be
equivalent to having per-cpu locks, which are deadlock-prone). We use
global rwlocks to get the deadlock-safety that we need.
From: Rusty Russell <hidden> Date: 2013-02-25 21:30:18
"Srivatsa S. Bhat" [off-list ref] writes:
Hi,
This patchset removes CPU hotplug's dependence on stop_machine() from the CPU
offline path and provides an alternative (set of APIs) to preempt_disable() to
prevent CPUs from going offline, which can be invoked from atomic context.
The motivation behind the removal of stop_machine() is to avoid its ill-effects
and thus improve the design of CPU hotplug. (More description regarding this
is available in the patches).
If you're doing a v7, please put your benchmark results somewhere!
The obvious place is in the 44/46.
Thanks,
Rusty.
From: Srivatsa S. Bhat <hidden> Date: 2013-02-25 21:47:22
On 02/22/2013 06:01 AM, Rusty Russell wrote:
"Srivatsa S. Bhat" [off-list ref] writes:
quoted
Hi,
This patchset removes CPU hotplug's dependence on stop_machine() from the CPU
offline path and provides an alternative (set of APIs) to preempt_disable() to
prevent CPUs from going offline, which can be invoked from atomic context.
The motivation behind the removal of stop_machine() is to avoid its ill-effects
and thus improve the design of CPU hotplug. (More description regarding this
is available in the patches).
If you're doing a v7, please put your benchmark results somewhere!
Oh, I forgot to put them in v6! Thanks for reminding :-)
And yes, I'll have to do a v7 to incorporate changes (if any) to the new code
that went in during this merge window.
The obvious place is in the 44/46.
Ok, will add it there. Thank you!
Regards,
Srivatsa S. Bhat
From: Lai Jiangshan <hidden> Date: 2013-02-26 00:17:34
On Tue, Feb 26, 2013 at 3:26 AM, Srivatsa S. Bhat
[off-list ref] wrote:
Hi Lai,
On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
quoted
Hi, Srivatsa,
The target of the whole patchset is nice for me.
Cool! Thanks :-)
quoted
A question: How did you find out the such usages of
"preempt_disable()" and convert them? did all are converted?
Well, I scanned through the source tree for usages which implicitly
disabled CPU offline and converted them over. Its not limited to uses
of preempt_disable() alone - even spin_locks, rwlocks, local_irq_disable()
etc also help disable CPU offline. So I tried to dig out all such uses
and converted them. However, since the merge window is open, a lot of
new code is flowing into the tree. So I'll have to rescan the tree to
see if there are any more places to convert.
quoted
And I think the lock is too complex and reinvent the wheel, why don't
you reuse the lglock?
lglocks? No way! ;-) See below...
quoted
I wrote an untested draft here.
Thanks,
Lai
PS: Some HA tools(I'm writing one) which takes checkpoints of
virtual-machines frequently, I guess this patchset can speedup the
tools.
From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <redacted>
Date: Mon, 25 Feb 2013 23:14:27 +0800
Subject: [PATCH] lglock: add read-preference local-global rwlock
locality via lglock(trylock)
read-preference read-write-lock via fallback rwlock_t
Signed-off-by: Lai Jiangshan <redacted>
---
include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
If I read the code above correctly, all you are doing is implementing a
recursive reader-side primitive (ie., allowing the reader to call these
functions recursively, without resulting in a self-deadlock).
But the thing is, making the reader-side recursive is the least of our
problems! Our main challenge is to make the locking extremely flexible
and also safe-guard it against circular-locking-dependencies and deadlocks.
Please take a look at the changelog of patch 1 - it explains the situation
with an example.
My lock fixes your requirements(I read patch 1-6 before I sent). In
readsite, lglock 's lock is token via trylock, the lglock doesn't
contribute to deadlocks, we can consider it doesn't exist when we find
deadlock from it. And global fallback rwlock doesn't result to
deadlocks because it is read-preference(you need to inc the
fallback_reader_refcnt inside the cpu-hotplug write-side, I don't do
it in generic lgrwlock)
If lg_rwlock_local_read_lock() spins, which means
lg_rwlock_local_read_lock() spins on fallback_rwlock, and which means
lg_rwlock_global_write_lock() took the lgrwlock successfully and
return, and which means lg_rwlock_local_read_lock() will stop spinning
when the write side finished.
This does a for-loop on all CPUs and takes their locks one-by-one. That's
exactly what we want to prevent, because that is the _source_ of all our
deadlock woes in this case. In the presence of perfect lock ordering
guarantees, this wouldn't have been a problem (that's why lglocks are
being used successfully elsewhere in the kernel). In the stop-machine()
removal case, the over-flexibility of preempt_disable() forces us to provide
an equally flexible locking alternative. Hence we can't use such per-cpu
locking schemes.
You might note that, for exactly this reason, I haven't actually used any
per-cpu _locks_ in this synchronization scheme, though it is named as
"per-cpu rwlocks". The only per-cpu component here are the refcounts, and
we consciously avoid waiting/spinning on them (because then that would be
equivalent to having per-cpu locks, which are deadlock-prone). We use
global rwlocks to get the deadlock-safety that we need.
From: Lai Jiangshan <hidden> Date: 2013-02-26 00:19:24
On Tue, Feb 26, 2013 at 8:17 AM, Lai Jiangshan [off-list ref] wrote:
On Tue, Feb 26, 2013 at 3:26 AM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
Hi Lai,
On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
quoted
Hi, Srivatsa,
The target of the whole patchset is nice for me.
Cool! Thanks :-)
quoted
A question: How did you find out the such usages of
"preempt_disable()" and convert them? did all are converted?
Well, I scanned through the source tree for usages which implicitly
disabled CPU offline and converted them over. Its not limited to uses
of preempt_disable() alone - even spin_locks, rwlocks, local_irq_disable()
etc also help disable CPU offline. So I tried to dig out all such uses
and converted them. However, since the merge window is open, a lot of
new code is flowing into the tree. So I'll have to rescan the tree to
see if there are any more places to convert.
quoted
And I think the lock is too complex and reinvent the wheel, why don't
you reuse the lglock?
lglocks? No way! ;-) See below...
quoted
I wrote an untested draft here.
Thanks,
Lai
PS: Some HA tools(I'm writing one) which takes checkpoints of
virtual-machines frequently, I guess this patchset can speedup the
tools.
From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <redacted>
Date: Mon, 25 Feb 2013 23:14:27 +0800
Subject: [PATCH] lglock: add read-preference local-global rwlock
locality via lglock(trylock)
read-preference read-write-lock via fallback rwlock_t
Signed-off-by: Lai Jiangshan <redacted>
---
include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
If I read the code above correctly, all you are doing is implementing a
recursive reader-side primitive (ie., allowing the reader to call these
functions recursively, without resulting in a self-deadlock).
But the thing is, making the reader-side recursive is the least of our
problems! Our main challenge is to make the locking extremely flexible
and also safe-guard it against circular-locking-dependencies and deadlocks.
Please take a look at the changelog of patch 1 - it explains the situation
with an example.
My lock fixes your requirements(I read patch 1-6 before I sent). In
s/fixes/fits/
readsite, lglock 's lock is token via trylock, the lglock doesn't
contribute to deadlocks, we can consider it doesn't exist when we find
deadlock from it. And global fallback rwlock doesn't result to
deadlocks because it is read-preference(you need to inc the
fallback_reader_refcnt inside the cpu-hotplug write-side, I don't do
it in generic lgrwlock)
If lg_rwlock_local_read_lock() spins, which means
lg_rwlock_local_read_lock() spins on fallback_rwlock, and which means
lg_rwlock_global_write_lock() took the lgrwlock successfully and
return, and which means lg_rwlock_local_read_lock() will stop spinning
when the write side finished.
This does a for-loop on all CPUs and takes their locks one-by-one. That's
exactly what we want to prevent, because that is the _source_ of all our
deadlock woes in this case. In the presence of perfect lock ordering
guarantees, this wouldn't have been a problem (that's why lglocks are
being used successfully elsewhere in the kernel). In the stop-machine()
removal case, the over-flexibility of preempt_disable() forces us to provide
an equally flexible locking alternative. Hence we can't use such per-cpu
locking schemes.
You might note that, for exactly this reason, I haven't actually used any
per-cpu _locks_ in this synchronization scheme, though it is named as
"per-cpu rwlocks". The only per-cpu component here are the refcounts, and
we consciously avoid waiting/spinning on them (because then that would be
equivalent to having per-cpu locks, which are deadlock-prone). We use
global rwlocks to get the deadlock-safety that we need.
From: Srivatsa S. Bhat <hidden> Date: 2013-02-26 09:05:14
On 02/26/2013 05:47 AM, Lai Jiangshan wrote:
On Tue, Feb 26, 2013 at 3:26 AM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
Hi Lai,
On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
quoted
Hi, Srivatsa,
The target of the whole patchset is nice for me.
Cool! Thanks :-)
[...]
quoted
quoted
I wrote an untested draft here.
Thanks,
Lai
PS: Some HA tools(I'm writing one) which takes checkpoints of
virtual-machines frequently, I guess this patchset can speedup the
tools.
From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <redacted>
Date: Mon, 25 Feb 2013 23:14:27 +0800
Subject: [PATCH] lglock: add read-preference local-global rwlock
locality via lglock(trylock)
read-preference read-write-lock via fallback rwlock_t
Signed-off-by: Lai Jiangshan <redacted>
---
include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
If I read the code above correctly, all you are doing is implementing a
recursive reader-side primitive (ie., allowing the reader to call these
functions recursively, without resulting in a self-deadlock).
But the thing is, making the reader-side recursive is the least of our
problems! Our main challenge is to make the locking extremely flexible
and also safe-guard it against circular-locking-dependencies and deadlocks.
Please take a look at the changelog of patch 1 - it explains the situation
with an example.
My lock fixes your requirements(I read patch 1-6 before I sent). In
readsite, lglock 's lock is token via trylock, the lglock doesn't
contribute to deadlocks, we can consider it doesn't exist when we find
deadlock from it. And global fallback rwlock doesn't result to
deadlocks because it is read-preference(you need to inc the
fallback_reader_refcnt inside the cpu-hotplug write-side, I don't do
it in generic lgrwlock)
Ah, since you hadn't mentioned the increment at the writer-side in your
previous email, I had missed the bigger picture of what you were trying
to achieve.
If lg_rwlock_local_read_lock() spins, which means
lg_rwlock_local_read_lock() spins on fallback_rwlock, and which means
lg_rwlock_global_write_lock() took the lgrwlock successfully and
return, and which means lg_rwlock_local_read_lock() will stop spinning
when the write side finished.
Unfortunately, I see quite a few issues with the code above. IIUC, the
writer and the reader both increment the same counters. So how will the
unlock() code in the reader path know when to unlock which of the locks?
(The counter-dropping-to-zero logic is not safe, since it can be updated
due to different reasons). And now that I look at it again, in the absence
of the writer, the reader is allowed to be recursive at the heavy cost of
taking the global rwlock for read, every 2nd time you nest (because the
spinlock is non-recursive). Also, this lg_rwlock implementation uses 3
different data-structures - a per-cpu spinlock, a global rwlock and
a per-cpu refcnt, and its not immediately apparent why you need those many
or even those many varieties. Also I see that this doesn't handle the
case of interrupt-handlers also being readers.
IMHO, the per-cpu rwlock scheme that I have implemented in this patchset
has a clean, understandable design and just enough data-structures/locks
to achieve its goal and has several optimizations (like reducing the
interrupts-disabled time etc) included - all in a very straight-forward
manner. Since this is non-trivial, IMHO, starting from a clean slate is
actually better than trying to retrofit the logic into some locking scheme
which we actively want to avoid (and hence effectively we aren't even
borrowing anything from!).
To summarize, if you are just pointing out that we can implement the same
logic by altering lglocks, then sure, I acknowledge the possibility.
However, I don't think doing that actually makes it better; it either
convolutes the logic unnecessarily, or ends up looking _very_ similar to
the implementation in this patchset, from what I can see.
Regards,
Srivatsa S. Bhat
From: Lai Jiangshan <hidden> Date: 2013-02-26 13:00:00
On Tue, Feb 26, 2013 at 5:02 PM, Srivatsa S. Bhat
[off-list ref] wrote:
On 02/26/2013 05:47 AM, Lai Jiangshan wrote:
quoted
On Tue, Feb 26, 2013 at 3:26 AM, Srivatsa S. Bhat
[off-list ref] wrote:
quoted
Hi Lai,
On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
quoted
Hi, Srivatsa,
The target of the whole patchset is nice for me.
Cool! Thanks :-)
[...]
quoted
quoted
quoted
I wrote an untested draft here.
Thanks,
Lai
PS: Some HA tools(I'm writing one) which takes checkpoints of
virtual-machines frequently, I guess this patchset can speedup the
tools.
From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <redacted>
Date: Mon, 25 Feb 2013 23:14:27 +0800
Subject: [PATCH] lglock: add read-preference local-global rwlock
locality via lglock(trylock)
read-preference read-write-lock via fallback rwlock_t
Signed-off-by: Lai Jiangshan <redacted>
---
include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
If I read the code above correctly, all you are doing is implementing a
recursive reader-side primitive (ie., allowing the reader to call these
functions recursively, without resulting in a self-deadlock).
But the thing is, making the reader-side recursive is the least of our
problems! Our main challenge is to make the locking extremely flexible
and also safe-guard it against circular-locking-dependencies and deadlocks.
Please take a look at the changelog of patch 1 - it explains the situation
with an example.
My lock fixes your requirements(I read patch 1-6 before I sent). In
readsite, lglock 's lock is token via trylock, the lglock doesn't
contribute to deadlocks, we can consider it doesn't exist when we find
deadlock from it. And global fallback rwlock doesn't result to
deadlocks because it is read-preference(you need to inc the
fallback_reader_refcnt inside the cpu-hotplug write-side, I don't do
it in generic lgrwlock)
Ah, since you hadn't mentioned the increment at the writer-side in your
previous email, I had missed the bigger picture of what you were trying
to achieve.
quoted
If lg_rwlock_local_read_lock() spins, which means
lg_rwlock_local_read_lock() spins on fallback_rwlock, and which means
lg_rwlock_global_write_lock() took the lgrwlock successfully and
return, and which means lg_rwlock_local_read_lock() will stop spinning
when the write side finished.
Unfortunately, I see quite a few issues with the code above. IIUC, the
writer and the reader both increment the same counters. So how will the
unlock() code in the reader path know when to unlock which of the locks?
The same as your code, the reader(which nested in write C.S.) just dec
the counters.
(The counter-dropping-to-zero logic is not safe, since it can be updated
due to different reasons). And now that I look at it again, in the absence
of the writer, the reader is allowed to be recursive at the heavy cost of
taking the global rwlock for read, every 2nd time you nest (because the
spinlock is non-recursive).
(I did not understand your comments of this part)
nested reader is considered seldom. But if N(>=2) nested readers happen,
the overhead is:
1 spin_try_lock() + 1 read_lock() + (N-1) __this_cpu_inc()
Also, this lg_rwlock implementation uses 3
different data-structures - a per-cpu spinlock, a global rwlock and
a per-cpu refcnt, and its not immediately apparent why you need those many
or even those many varieties.
data-structures is the same as yours.
fallback_reader_refcnt <--> reader_refcnt
per-cpu spinlock <--> write_signal
fallback_rwlock <---> global_rwlock
Also I see that this doesn't handle the
case of interrupt-handlers also being readers.
handled. nested reader will see the ref or take the fallback_rwlock
IMHO, the per-cpu rwlock scheme that I have implemented in this patchset
has a clean, understandable design and just enough data-structures/locks
to achieve its goal and has several optimizations (like reducing the
interrupts-disabled time etc) included - all in a very straight-forward
manner. Since this is non-trivial, IMHO, starting from a clean slate is
actually better than trying to retrofit the logic into some locking scheme
which we actively want to avoid (and hence effectively we aren't even
borrowing anything from!).
To summarize, if you are just pointing out that we can implement the same
logic by altering lglocks, then sure, I acknowledge the possibility.
However, I don't think doing that actually makes it better; it either
convolutes the logic unnecessarily, or ends up looking _very_ similar to
the implementation in this patchset, from what I can see.
Regards,
Srivatsa S. Bhat
From: Lai Jiangshan <hidden> Date: 2013-02-26 13:34:15
On Tue, Feb 26, 2013 at 3:26 AM, Srivatsa S. Bhat
[off-list ref] wrote:
Hi Lai,
On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
quoted
Hi, Srivatsa,
The target of the whole patchset is nice for me.
Cool! Thanks :-)
quoted
A question: How did you find out the such usages of
"preempt_disable()" and convert them? did all are converted?
Well, I scanned through the source tree for usages which implicitly
disabled CPU offline and converted them over.
How do you scan? could you show the way you scan the source tree.
I can follow your instructions for double checking.
Its not limited to uses
of preempt_disable() alone - even spin_locks, rwlocks, local_irq_disable()
etc also help disable CPU offline. So I tried to dig out all such uses
and converted them. However, since the merge window is open, a lot of
new code is flowing into the tree. So I'll have to rescan the tree to
see if there are any more places to convert.
I remember some code has such assumption:
preempt_disable() (or something else)
//the code assume that the cpu_online_map can't be changed.
preempt_enable()
It is very hard to find out all such kinds of assumptions and fixes them.
(I notice your code mainly fixes code around send_xxxx())
quoted
And I think the lock is too complex and reinvent the wheel, why don't
you reuse the lglock?
lglocks? No way! ;-) See below...
quoted
I wrote an untested draft here.
Thanks,
Lai
PS: Some HA tools(I'm writing one) which takes checkpoints of
virtual-machines frequently, I guess this patchset can speedup the
tools.
From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <redacted>
Date: Mon, 25 Feb 2013 23:14:27 +0800
Subject: [PATCH] lglock: add read-preference local-global rwlock
locality via lglock(trylock)
read-preference read-write-lock via fallback rwlock_t
Signed-off-by: Lai Jiangshan <redacted>
---
include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
If I read the code above correctly, all you are doing is implementing a
recursive reader-side primitive (ie., allowing the reader to call these
functions recursively, without resulting in a self-deadlock).
But the thing is, making the reader-side recursive is the least of our
problems! Our main challenge is to make the locking extremely flexible
and also safe-guard it against circular-locking-dependencies and deadlocks.
Please take a look at the changelog of patch 1 - it explains the situation
with an example.
This does a for-loop on all CPUs and takes their locks one-by-one. That's
exactly what we want to prevent, because that is the _source_ of all our
deadlock woes in this case. In the presence of perfect lock ordering
guarantees, this wouldn't have been a problem (that's why lglocks are
being used successfully elsewhere in the kernel). In the stop-machine()
removal case, the over-flexibility of preempt_disable() forces us to provide
an equally flexible locking alternative. Hence we can't use such per-cpu
locking schemes.
You might note that, for exactly this reason, I haven't actually used any
per-cpu _locks_ in this synchronization scheme, though it is named as
"per-cpu rwlocks". The only per-cpu component here are the refcounts, and
we consciously avoid waiting/spinning on them (because then that would be
equivalent to having per-cpu locks, which are deadlock-prone). We use
global rwlocks to get the deadlock-safety that we need.
From: Lai Jiangshan <hidden> Date: 2013-02-26 14:17:07
On Mon, Feb 18, 2013 at 8:38 PM, Srivatsa S. Bhat
[off-list ref] wrote:
Using global rwlocks as the backend for per-CPU rwlocks helps us avoid many
lock-ordering related problems (unlike per-cpu locks). However, global
rwlocks lead to unnecessary cache-line bouncing even when there are no
writers present, which can slow down the system needlessly.
per-CPU rwlocks(yours and mine) are the exactly same as rwlock_t in
the view of lock dependency(except reader-C.S. can be nested in
writer-C.S.)
so they can deadlock in this order:
spin_lock(some_lock); percpu_write_lock_irqsave()
case CPU_DYING
percpu_read_lock_irqsafe(); <---deadlock---> spin_lock(some_lock);
The lockdep can find out such dependency, but we must try our best to
find out them before merge the patchset to mainline. We can review
all the code of cpu_disable() and CPU_DYING and fix this kinds of lock
dependency, but it is not easy thing, it may be a long term project.
======
And if there is any CPU_DYING code takes no locks and do some
works(because they know they are called via stop_machine()) we need to
add that locking code back if there is such code.(I don't know whether
such code exist or not)
quoted hunk
Per-cpu counters can help solve the cache-line bouncing problem. So we
actually use the best of both: per-cpu counters (no-waiting) at the reader
side in the fast-path, and global rwlocks in the slowpath.
[ Fastpath = no writer is active; Slowpath = a writer is active ]
IOW, the readers just increment/decrement their per-cpu refcounts (disabling
interrupts during the updates, if necessary) when no writer is active.
When a writer becomes active, he signals all readers to switch to global
rwlocks for the duration of his activity. The readers switch over when it
is safe for them (ie., when they are about to start a fresh, non-nested
read-side critical section) and start using (holding) the global rwlock for
read in their subsequent critical sections.
The writer waits for every existing reader to switch, and then acquires the
global rwlock for write and enters his critical section. Later, the writer
signals all readers that he is done, and that they can go back to using their
per-cpu refcounts again.
Note that the lock-safety (despite the per-cpu scheme) comes from the fact
that the readers can *choose* _when_ to switch to rwlocks upon the writer's
signal. And the readers don't wait on anybody based on the per-cpu counters.
The only true synchronization that involves waiting at the reader-side in this
scheme, is the one arising from the global rwlock, which is safe from circular
locking dependency issues.
Reader-writer locks and per-cpu counters are recursive, so they can be
used in a nested fashion in the reader-path, which makes per-CPU rwlocks also
recursive. Also, this design of switching the synchronization scheme ensures
that you can safely nest and use these locks in a very flexible manner.
I'm indebted to Michael Wang and Xiao Guangrong for their numerous thoughtful
suggestions and ideas, which inspired and influenced many of the decisions in
this as well as previous designs. Thanks a lot Michael and Xiao!
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Srivatsa S. Bhat <redacted>
---
lib/percpu-rwlock.c | 139 ++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 137 insertions(+), 2 deletions(-)
@@ -55,21 +73,138 @@ void percpu_free_rwlock(struct percpu_rwlock *pcpu_rwlock)voidpercpu_read_lock(structpercpu_rwlock*pcpu_rwlock){-read_lock(&pcpu_rwlock->global_rwlock);+preempt_disable();++/*+*Letthewriterknowthatareaderisactive,evenbeforewechoose+*ourreader-sidesynchronizationscheme.+*/+this_cpu_inc(pcpu_rwlock->rw_state->reader_refcnt);++/*+*Ifwearealreadyusingper-cpurefcounts,itisnotsafetoswitch+*thesynchronizationscheme.Socontinueusingtherefcounts.+*/+if(reader_nested_percpu(pcpu_rwlock))+return;++/*+*Thewriteto'reader_refcnt'mustbevisiblebeforeweread+*'writer_signal'.+*/+smp_mb();++if(likely(!writer_active(pcpu_rwlock))){+gotoout;+}else{+/* Writer is active, so switch to global rwlock. */+read_lock(&pcpu_rwlock->global_rwlock);++/*+*Wemighthaveracedwithawritergoinginactivebeforewe+*tooktheread-lock.Sore-evaluatewhetherwestillneedto+*holdtherwlockorifwecanswitchbacktoper-cpu+*refcounts.(Thisalsohelpsavoidheterogeneousnestingof+*readers).+*/+if(writer_active(pcpu_rwlock)){+/*+*Theabovewriter_active()checkcangetreordered+*withthis_cpu_dec()below,butthisisOK,because+*holdingtherwlockisconservative.+*/+this_cpu_dec(pcpu_rwlock->rw_state->reader_refcnt);+}else{+read_unlock(&pcpu_rwlock->global_rwlock);+}+}++out:+/* Prevent reordering of any subsequent reads/writes */+smp_mb();}voidpercpu_read_unlock(structpercpu_rwlock*pcpu_rwlock){-read_unlock(&pcpu_rwlock->global_rwlock);+/*+*Weneverallowheterogeneousnestingofreaders.Soitistrivial+*tofindoutthekindofreaderweare,andundotheoperation+*donebyourcorrespondingpercpu_read_lock().+*/++/* Try to fast-path: a nested percpu reader is the simplest case */+if(reader_nested_percpu(pcpu_rwlock)){+this_cpu_dec(pcpu_rwlock->rw_state->reader_refcnt);+preempt_enable();+return;+}++/*+*Nowweareleftwithonly2options:anon-nestedpercpureader,+*orareaderholdingrwlock+*/+if(reader_uses_percpu_refcnt(pcpu_rwlock)){+/*+*Completethecriticalsectionbeforedecrementingthe+*refcnt.Wecanoptimizethisawayifweareanested+*reader(thecaseabove).+*/+smp_mb();+this_cpu_dec(pcpu_rwlock->rw_state->reader_refcnt);+}else{+read_unlock(&pcpu_rwlock->global_rwlock);+}++preempt_enable();}voidpercpu_write_lock(structpercpu_rwlock*pcpu_rwlock){+unsignedintcpu;++/*+*Tellallreadersthatawriterisbecomingactive,sothatthey+*startswitchingovertotheglobalrwlock.+*/+for_each_possible_cpu(cpu)+per_cpu_ptr(pcpu_rwlock->rw_state,cpu)->writer_signal=true;++smp_mb();++/*+*Waitforeveryreadertoseethewriter'ssignalandswitchfrom+*percpurefcountstoglobalrwlock.+*+*Ifareaderisstillusingpercpurefcounts,waitforhimtoswitch.+*Else,wecansafelygoahead,becauseeitherthereaderhasalready+*switchedover,orthenextreaderthatcomesalongonthatCPUwill+*noticethewriter'ssignalandwillswitchovertotherwlock.+*/++for_each_possible_cpu(cpu){+while(reader_yet_to_switch(pcpu_rwlock,cpu))+cpu_relax();+}++smp_mb();/* Complete the wait-for-readers, before taking the lock */write_lock(&pcpu_rwlock->global_rwlock);}voidpercpu_write_unlock(structpercpu_rwlock*pcpu_rwlock){+unsignedintcpu;++/* Complete the critical section before clearing ->writer_signal */+smp_mb();++/*+*Informallreadersthatwearedone,sothattheycanswitchback+*totheirper-cpurefcounts.(Wedon'tneedtowaitforthemto+*seeit).+*/+for_each_possible_cpu(cpu)+per_cpu_ptr(pcpu_rwlock->rw_state,cpu)->writer_signal=false;+write_unlock(&pcpu_rwlock->global_rwlock);}--