locking/Documentation: Insert white spaces consistently
The document uses two newlines between sections, one newline between item and its detailed description, and two spaces between sentences. There are a few places that used these rules inconsistently - fix them. Signed-off-by: SeongJae Park <sj38.park@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: David Howells <dhowells@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bobby.prani@gmail.com Cc: dipankar@in.ibm.com Cc: dvhart@linux.intel.com Cc: edumazet@google.com Cc: fweisbec@gmail.com Cc: jiangshanlai@gmail.com Cc: josh@joshtriplett.org Cc: mathieu.desnoyers@efficios.com Cc: oleg@redhat.com Cc: rostedt@goodmis.org Link: http://lkml.kernel.org/r/1460476375-27803-5-git-send-email-paulmck@linux.vnet.ibm.com [ Fixed the changelog. ] Signed-off-by: Ingo Molnar <mingo@kernel.org>hifive-unleashed-5.1
parent
3dbf0913f6
commit
0b6fa347dc
|
@ -1796,6 +1796,7 @@ There are some more advanced barrier functions:
|
|||
|
||||
|
||||
(*) lockless_dereference();
|
||||
|
||||
This can be thought of as a pointer-fetch wrapper around the
|
||||
smp_read_barrier_depends() data-dependency barrier.
|
||||
|
||||
|
@ -2092,9 +2093,9 @@ or:
|
|||
event_indicated = 1;
|
||||
wake_up_process(event_daemon);
|
||||
|
||||
A write memory barrier is implied by wake_up() and co. if and only if they wake
|
||||
something up. The barrier occurs before the task state is cleared, and so sits
|
||||
between the STORE to indicate the event and the STORE to set TASK_RUNNING:
|
||||
A write memory barrier is implied by wake_up() and co. if and only if they
|
||||
wake something up. The barrier occurs before the task state is cleared, and so
|
||||
sits between the STORE to indicate the event and the STORE to set TASK_RUNNING:
|
||||
|
||||
CPU 1 CPU 2
|
||||
=============================== ===============================
|
||||
|
@ -2488,9 +2489,9 @@ The following operations are special locking primitives:
|
|||
clear_bit_unlock();
|
||||
__clear_bit_unlock();
|
||||
|
||||
These implement ACQUIRE-class and RELEASE-class operations. These should be used in
|
||||
preference to other operations when implementing locking primitives, because
|
||||
their implementations can be optimised on many architectures.
|
||||
These implement ACQUIRE-class and RELEASE-class operations. These should be
|
||||
used in preference to other operations when implementing locking primitives,
|
||||
because their implementations can be optimised on many architectures.
|
||||
|
||||
[!] Note that special memory barrier primitives are available for these
|
||||
situations because on some CPUs the atomic instructions used imply full memory
|
||||
|
@ -2589,8 +2590,8 @@ functions:
|
|||
(*) inX(), outX():
|
||||
|
||||
These are intended to talk to I/O space rather than memory space, but
|
||||
that's primarily a CPU-specific concept. The i386 and x86_64 processors do
|
||||
indeed have special I/O space access cycles and instructions, but many
|
||||
that's primarily a CPU-specific concept. The i386 and x86_64 processors
|
||||
do indeed have special I/O space access cycles and instructions, but many
|
||||
CPUs don't have such a concept.
|
||||
|
||||
The PCI bus, amongst others, defines an I/O space concept which - on such
|
||||
|
@ -3042,6 +3043,7 @@ The Alpha defines the Linux kernel's memory barrier model.
|
|||
|
||||
See the subsection on "Cache Coherency" above.
|
||||
|
||||
|
||||
VIRTUAL MACHINE GUESTS
|
||||
----------------------
|
||||
|
||||
|
@ -3060,6 +3062,7 @@ These are equivalent to smp_mb() etc counterparts in all other respects,
|
|||
in particular, they do not control MMIO effects: to control
|
||||
MMIO effects, use mandatory barriers.
|
||||
|
||||
|
||||
============
|
||||
EXAMPLE USES
|
||||
============
|
||||
|
|
Loading…
Reference in New Issue