Searched refs:ordering (Results 1 – 25 of 114) sorted by relevance
12345
| /Linux-v4.19/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
77 Memory ordering guarantee changes:
90 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-v4.19/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 | README | 37 Tests whether the ordering provided by a lock-protected S
138 Is the ordering provided by a spin_unlock() and a subsequent
139 spin_lock() sufficient to make ordering apparent to accesses
147 Is the ordering provided by a release-acquire chain sufficient
148 to make ordering apparent to accesses by a process that does
|
| 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 | MP+fencewmbonceonce+fencermbonceonce.litmus | 7 * sufficient ordering for the message-passing pattern. However, it
|
| D | SB+poonceonces.litmus | 6 * This litmus test demonstrates that at least some ordering is required
|
| D | WRC+poonceonces+Once.litmus | 8 * test has no ordering at all.
|
| D | ISA2+pooncelock+pooncelock+pombonce.litmus | 6 * This test shows that the ordering provided by a lock-protected S
|
| D | LB+fencembonceonce+ctrlonceonce.litmus | 6 * This litmus test demonstrates that lightweight ordering suffices for
|
| /Linux-v4.19/tools/memory-model/ |
| D | linux-kernel.cat | 44 (* Fundamental coherence ordering *)
55 (* Instruction execution ordering *)
80 (* Write and fence propagation ordering *)
123 * expressions of temporal ordering. They could be replaced by
|
| D | lock.cat | 30 * LKR, LF, RL, and RU are read events; LKR has Acquire ordering.
31 * LKW and UL are write events; UL has Release ordering.
32 * LKW, LF, RL, and RU have no ordering properties.
39 (* Treat RL as a kind of LF: a read with no ordering properties *)
|
| /Linux-v4.19/arch/arm/lib/ |
| D | findbit.S | 107 1: eor r3, r2, #0x18 @ big endian byte ordering
125 eor r3, r2, #0x18 @ big endian byte ordering
141 1: eor r3, r2, #0x18 @ big endian byte ordering
159 eor r3, r2, #0x18 @ big endian byte ordering
|
| /Linux-v4.19/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 …]
|
| D | references.txt | 84 Alan Stern. 2017. "A formal kernel memory-ordering model (part 1)"
88 Alan Stern. 2017. "A formal kernel memory-ordering model (part 2)"
|
| /Linux-v4.19/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-v4.19/Documentation/driver-api/ |
| 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.
111 order intended. Issuing a regular readX() will also ensure write ordering,
119 aren't surrounded by readb() calls, which will ensure ordering
121 write ordering isn't guaranteed via :c:func:`mmiowb()` or one of the
151 PCI ordering rules also guarantee that PIO read responses arrive after any
|
| D | device_link.rst | 24 suspend/resume and shutdown ordering.
29 It guarantees correct suspend/resume and shutdown ordering between a
36 suspend/resume and shutdown ordering is needed, the device link may
78 shutdown ordering) and ``DL_FLAG_PM_RUNTIME`` to express that runtime PM
169 suspend/resume ordering, this needs to be implemented separately.
173 ordering or a driver presence dependency.
176 device link and does not allow for shutdown ordering or driver presence
210 correct suspend/resume and shutdown ordering between parent and child,
|
| /Linux-v4.19/Documentation/devicetree/bindings/serial/ |
| D | vt8500-uart.txt | 15 Aliases may be defined to ensure the correct ordering of the uarts.
|
| /Linux-v4.19/Documentation/ |
| D | atomic_t.txt | 155 Except of course when an operation has an explicit ordering like:
173 only apply to the RMW ops and can be used to augment/upgrade the ordering
177 ordering on their SMP atomic primitives. For example our TSO architectures
|
| 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.
646 of dependency ordering is to -prevent- writes to the data structure, along
649 naturally occurring ordering prevents such records from being lost.
[all …]
|
12345
