Searched refs:ordering (Results 1 – 25 of 141) sorted by relevance
123456
/linux-6.1.9/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 …]
|
/linux-6.1.9/tools/memory-model/Documentation/ ! |
D | ordering.txt | 1 This document gives an overview of the categories of memory-ordering 8 This section lists LKMM's three top-level categories of memory-ordering 20 3. Unordered accesses, as the name indicates, have no ordering 23 some of these "unordered" operations provide limited ordering 38 b. Read-modify-write (RMW) ordering augmentation barriers. 50 ordering primitives provided for that purpose. For example, instead of 58 The Linux-kernel primitives that provide full ordering include: 79 memory-ordering primitives. It is surprisingly hard to remember their 82 Second, some RMW atomic operations provide full ordering. These 87 as cmpxchg() are only guaranteed to provide ordering when they succeed. [all …]
|
D | control-dependencies.txt | 12 Therefore, a load-load control dependency will not preserve ordering 19 This is not guaranteed to provide any ordering because some types of CPUs 31 However, stores are not speculated. This means that ordering is 40 of ordering. But please note that neither the READ_ONCE() nor the 59 It is tempting to try use control dependencies to enforce ordering on 78 WRITE_ONCE(b, 1); /* BUG: No ordering vs. load from a!!! */ 91 have been applied. Therefore, if you need ordering in this example, 92 you must use explicit memory ordering, for example, smp_store_release(): 103 Without explicit memory ordering, control-dependency-based ordering is 121 preserve ordering. For example: [all …]
|
D | simple.txt | 2 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 …]
|
D | README | 16 that the Linux kernel provides: ordering.txt 64 ordering.txt 65 Overview of the Linux kernel's low-level memory-ordering 69 Common memory-ordering patterns.
|
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 | cheatsheet.txt | 29 Y: Provides ordering 30 a: Provides ordering given intervening RMW atomic operation
|
/linux-6.1.9/Documentation/RCU/Design/Memory-Ordering/ ! |
D | Tree-RCU-Memory-Ordering.rst | 13 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 126 | Because we must provide ordering for RCU's polling grace-period | 145 RCU's grace-period memory ordering guarantee to extend to any 173 might not yet be subject to the grace period's memory ordering. 193 Tree RCU's grace--period memory-ordering guarantees rely most heavily on 197 shown below, which is one of several functions that enforce ordering of [all …]
|
/linux-6.1.9/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 | 39 Tests whether the ordering provided by a lock-protected S 67 Does a unlock+lock pair provides ordering guarantee between a 98 Does a unlock+lock pair provides ordering guarantee between a 148 Is the ordering provided by a spin_unlock() and a subsequent 149 spin_lock() sufficient to make ordering apparent to accesses 157 Is the ordering provided by a release-acquire chain sufficient 158 to make ordering apparent to accesses by a process that does
|
D | LB+poonceonces.litmus | 7 * be prevented even with no explicit ordering?
|
D | MP+poonceonces.litmus | 7 * no ordering at all?
|
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
|
/linux-6.1.9/virt/kvm/ ! |
D | Kconfig | 23 # put any explicit constraint on userspace ordering. They can also 31 # to userspace the additional ordering requirements.
|
/linux-6.1.9/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-6.1.9/Documentation/filesystems/ ! |
D | inotify.rst | 50 - 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-6.1.9/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-6.1.9/Documentation/ ! |
D | memory-barriers.txt | 87 (*) 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 An address-dependency barrier is a partial ordering on interdependent 421 showing the ordering constraints. 445 A read barrier is a partial ordering on loads only; it is not required to 462 A general memory barrier is a partial ordering over both loads and stores. 653 of dependency ordering is to -prevent- writes to the data structure, along 656 naturally occurring ordering prevents such records from being lost. [all …]
|
/linux-6.1.9/Documentation/driver-api/ ! |
D | device_link.rst | 23 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