Searched refs:ordering (Results 1 – 25 of 116) sorted by relevance
12345
| /Linux-v5.4/Documentation/core-api/ |
| D | refcount-vs-atomic.rst | 14 ``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 …]
|
| D | circular-buffers.rst | 159 /* 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.4/tools/memory-model/litmus-tests/ |
| D | S+poonceonces.litmus | 6 * Starting with a two-process release-acquire chain ordering P0()'s
9 * READ_ONCE(), is ordering preserved?
|
| D | ISA2+poonceonces.litmus | 6 * 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
|
| D | MP+poonceonces.litmus | 7 * no ordering at all?
|
| D | LB+poonceonces.litmus | 7 * be prevented even with no explicit ordering?
|
| D | MP+pooncerelease+poacquireonce.litmus | 7 * smp_load_acquire() provide sufficient ordering for the message-passing
|
| D | SB+poonceonces.litmus | 6 * This litmus test demonstrates that at least some ordering is required
|
| D | MP+fencewmbonceonce+fencermbonceonce.litmus | 7 * sufficient ordering for the message-passing pattern. However, it
|
| D | WRC+poonceonces+Once.litmus | 8 * test has no ordering at all.
|
| D | ISA2+pooncelock+pooncelock+pombonce.litmus | 6 * This test shows that write-write ordering provided by locks
|
| D | LB+fencembonceonce+ctrlonceonce.litmus | 6 * This litmus test demonstrates that lightweight ordering suffices for
|
| D | README | 39 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.4/arch/arm/lib/ |
| D | findbit.S | 104 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.4/tools/memory-model/Documentation/ |
| D | cheatsheet.txt | 24 Y: Provides ordering
25 a: Provides ordering given intervening RMW atomic operation
|
| D | recipes.txt | 41 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 …]
|
| /Linux-v5.4/Documentation/filesystems/ |
| D | inotify.txt | 41 - There would be no way to get event ordering. Events on file foo and
43 which happened first. A single queue trivially gives you ordering. Such
44 ordering is crucial to existing applications such as Beagle. Imagine
45 "mv a b ; mv b a" events without ordering.
|
| /Linux-v5.4/tools/memory-model/ |
| D | lock.cat | 27 * 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 *)
|
| D | linux-kernel.cat | 53 (* 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.4/Documentation/ |
| D | memory-barriers.txt | 89 (*) Assumed minimum execution ordering model.
139 abstract CPU, memory operation ordering is very relaxed, and a CPU may actually
367 ordering over the memory operations on either side of the barrier.
389 A write barrier is a partial ordering on stores only; it is not required
409 A data dependency barrier is a partial ordering on interdependent loads
423 showing the ordering constraints.
443 A read barrier is a partial ordering on loads only; it is not required to
460 A general memory barrier is a partial ordering over both loads and stores.
645 of dependency ordering is to -prevent- writes to the data structure, along
648 naturally occurring ordering prevents such records from being lost.
[all …]
|
| D | atomic_t.txt | 174 Except of course when an operation has an explicit ordering like:
193 ordering inherent to the op. These barriers act almost like a full smp_mb():
202 ordering on their SMP atomic primitives. For example our TSO architectures
|
| /Linux-v5.4/Documentation/devicetree/bindings/serial/ |
| D | vt8500-uart.txt | 15 Aliases may be defined to ensure the correct ordering of the uarts.
|
| /Linux-v5.4/Documentation/driver-api/ |
| D | device_link.rst | 27 suspend/resume and shutdown ordering.
32 types: It guarantees correct suspend/resume and shutdown ordering between a
39 suspend/resume and shutdown ordering is needed, the device link may
87 shutdown ordering) and ``DL_FLAG_PM_RUNTIME`` to express that runtime PM
208 suspend/resume ordering, this needs to be implemented separately.
212 ordering or a driver presence dependency.
215 device link and does not allow for shutdown ordering or driver presence
249 correct suspend/resume and shutdown ordering between parent and child,
|
| D | device-io.rst | 69 compiler is not permitted to reorder the I/O sequence. When the ordering
71 indicate the relaxed ordering. Use this with care.
106 PCI ordering rules also guarantee that PIO read responses arrive after any
|
| /Linux-v5.4/Documentation/devicetree/bindings/media/ |
| D | aspeed-video.txt | 11 the VE (ordering must match the clock-names property)
|
12345
