Home
last modified time | relevance | path

Searched refs:ordering (Results 1 – 25 of 129) sorted by relevance

123456

/Linux-v5.10/Documentation/core-api/
Drefcount-vs-atomic.rst14 ``atomic_*()`` functions with regards to the memory ordering guarantees.
17 these memory ordering guarantees.
23 memory ordering in general and for atomic operations specifically.
25 Relevant types of memory ordering
29 ordering types that are relevant for the atomics and reference
33 In the absence of any memory ordering guarantees (i.e. fully unordered)
41 A strong (full) memory ordering guarantees that all prior loads and
49 A RELEASE memory ordering guarantees that all prior loads and
57 An ACQUIRE memory ordering guarantees that all post loads and
84 Memory ordering guarantee changes:
[all …]
Dcircular-buffers.rst159 /* The spin_unlock() and next spin_lock() provide needed ordering. */
183 is actually awakened. We therefore cannot rely on it for ordering. However,
188 ordering between the read of the index indicating that the consumer has
229 prevents the compiler from tearing the store, and enforces ordering
/Linux-v5.10/Documentation/RCU/Design/Memory-Ordering/
DTree-RCU-Memory-Ordering.rst13 grace-period memory ordering guarantee is provided.
18 RCU grace periods provide extremely strong memory-ordering guarantees
49 The workhorse for RCU's grace-period memory ordering is the
72 Tree RCU uses these two ordering guarantees to form an ordering
77 The following litmus test exhibits the ordering effects of these
116 RCU's grace-period memory ordering guarantee to extend to any
144 might not yet be subject to the grace period's memory ordering.
164 Tree RCU's grace--period memory-ordering guarantees rely most heavily on
168 shown below, which is one of several functions that enforce ordering of
230 Tree RCU's grace-period memory-ordering guarantee is provided by a
[all …]
/Linux-v5.10/tools/memory-model/litmus-tests/
DS+poonceonces.litmus6 * Starting with a two-process release-acquire chain ordering P0()'s
9 * READ_ONCE(), is ordering preserved?
DISA2+poonceonces.litmus6 * Given a release-acquire chain ordering the first process's store
7 * against the last process's load, is ordering preserved if all of the
DMP+poonceonces.litmus7 * no ordering at all?
DMP+pooncerelease+poacquireonce.litmus7 * smp_load_acquire() provide sufficient ordering for the message-passing
DLB+poonceonces.litmus7 * be prevented even with no explicit ordering?
DSB+poonceonces.litmus6 * This litmus test demonstrates that at least some ordering is required
DMP+fencewmbonceonce+fencermbonceonce.litmus7 * sufficient ordering for the message-passing pattern. However, it
DWRC+poonceonces+Once.litmus8 * test has no ordering at all.
DISA2+pooncelock+pooncelock+pombonce.litmus6 * This test shows that write-write ordering provided by locks
DLB+fencembonceonce+ctrlonceonce.litmus6 * This litmus test demonstrates that lightweight ordering suffices for
DREADME39 Tests whether the ordering provided by a lock-protected S
140 Is the ordering provided by a spin_unlock() and a subsequent
141 spin_lock() sufficient to make ordering apparent to accesses
149 Is the ordering provided by a release-acquire chain sufficient
150 to make ordering apparent to accesses by a process that does
/Linux-v5.10/tools/memory-model/Documentation/
Dsimple.txt2 memory-ordering lives simple, as is necessary for those whose domain
3 is complex. After all, there are bugs other than memory-ordering bugs,
4 and the time spent gaining memory-ordering knowledge is not available
139 memory ordering.
175 2. Operations that did not return a value and provided no ordering,
178 3. Operations that returned a value and provided full ordering, such as
180 value-returning operations provide full ordering only conditionally.
181 For example, cmpxchg() provides ordering only upon success.
184 provide full ordering. These are flagged with either a _relaxed()
185 suffix (providing no ordering), or an _acquire() or _release() suffix
[all …]
Drecipes.txt41 your full-ordering warranty, as do undersized accesses that load
157 lock's ordering properties.
208 In the absence of any ordering, this goal may not be met, as can be seen
217 the desired MP ordering. The general approach is shown below:
272 The rcu_assign_pointer() macro has the same ordering properties as does
357 absence of any ordering it is quite possible that this may happen, as
434 The ordering in this example is stronger than it needs to be. For
435 example, ordering would still be preserved if CPU1()'s smp_load_acquire()
468 well as simple and powerful, at least as memory-ordering mechanisms go.
500 of ordering wakeups. The following comment taken from waitqueue_active()
[all …]
Dcheatsheet.txt29 Y: Provides ordering
30 a: Provides ordering given intervening RMW atomic operation
/Linux-v5.10/arch/arm/lib/
Dfindbit.S104 1: eor r3, r2, #0x18 @ big endian byte ordering
122 eor r3, r2, #0x18 @ big endian byte ordering
138 1: eor r3, r2, #0x18 @ big endian byte ordering
156 eor r3, r2, #0x18 @ big endian byte ordering
/Linux-v5.10/Documentation/filesystems/
Dinotify.rst50 - There would be no way to get event ordering. Events on file foo and
52 which happened first. A single queue trivially gives you ordering. Such
53 ordering is crucial to existing applications such as Beagle. Imagine
54 "mv a b ; mv b a" events without ordering.
/Linux-v5.10/tools/memory-model/
Dlock.cat27 * LKR, LF, RL, and RU are read events; LKR has Acquire ordering.
28 * LKW and UL are write events; UL has Release ordering.
29 * LKW, LF, RL, and RU have no ordering properties.
36 (* Treat RL as a kind of LF: a read with no ordering properties *)
Dlinux-kernel.cat53 (* Fundamental coherence ordering *)
64 (* Instruction execution ordering *)
90 (* Write and fence propagation ordering *)
152 * expressions of temporal ordering. They could be replaced by
/Linux-v5.10/Documentation/
Dmemory-barriers.txt87 (*) Assumed minimum execution ordering model.
137 abstract CPU, memory operation ordering is very relaxed, and a CPU may actually
365 ordering over the memory operations on either side of the barrier.
387 A write barrier is a partial ordering on stores only; it is not required
407 A data dependency barrier is a partial ordering on interdependent loads
421 showing the ordering constraints.
441 A read barrier is a partial ordering on loads only; it is not required to
458 A general memory barrier is a partial ordering over both loads and stores.
642 of dependency ordering is to -prevent- writes to the data structure, along
645 naturally occurring ordering prevents such records from being lost.
[all …]
/Linux-v5.10/Documentation/dev-tools/
Dkcsan.rst201 The LKMM defines the propagation and ordering rules of various memory
207 ``atomic_*``, etc.), but is oblivious of any ordering guarantees and simply
213 memory ordering. Developers should therefore carefully consider the required
214 memory ordering requirements that remain unchecked. If, however, missing
215 memory ordering (that is observable with a particular compiler and
293 5. **Memory Ordering:** KCSAN is *not* explicitly aware of the LKMM's ordering
309 To build a correct happens-before relation, KTSAN must be aware of all ordering
/Linux-v5.10/Documentation/devicetree/bindings/serial/
Dvt8500-uart.txt15 Aliases may be defined to ensure the correct ordering of the uarts.
/Linux-v5.10/Documentation/driver-api/
Ddevice_link.rst23 suspend/resume and shutdown ordering.
28 types: It guarantees correct suspend/resume and shutdown ordering between a
35 suspend/resume and shutdown ordering is needed, the device link may
83 shutdown ordering) and ``DL_FLAG_PM_RUNTIME`` to express that runtime PM
204 suspend/resume ordering, this needs to be implemented separately.
208 ordering or a driver presence dependency.
211 device link and does not allow for shutdown ordering or driver presence
245 correct suspend/resume and shutdown ordering between parent and child,

123456