Searched full:ordering (Results 1 – 25 of 854) sorted by relevance
12345678910>>...35
| /Linux-v5.10/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-v5.10/arch/csky/include/asm/ |
| D | barrier.h | 19 * bar.brwarw: ordering barrier for all load/store instructions before it
20 * bar.brwarws: ordering barrier for all load/store instructions before it
22 * bar.brar: ordering barrier for all load instructions before it
23 * bar.brars: ordering barrier for all load instructions before it
25 * bar.bwaw: ordering barrier for all store instructions before it
26 * bar.bwaws: ordering barrier for all store instructions before it
|
| /Linux-v5.10/include/linux/ |
| D | refcount.h | 60 * Memory ordering
63 * Memory ordering rules are slightly relaxed wrt regular atomic_t functions
66 * The increments are fully relaxed; these will not provide ordering. The
68 * reference count on will provide the ordering. For locked data structures,
84 * Note that the allocator is responsible for ordering things between free()
88 * ordering on success.
175 * Provides no memory ordering, it is assumed the caller has guaranteed the
211 * Provides no memory ordering, it is assumed the caller has guaranteed the
237 * Provides no memory ordering, it is assumed the caller has guaranteed the
259 * Provides no memory ordering, it is assumed the caller already has a
[all …]
|
| /Linux-v5.10/tools/memory-model/Documentation/ |
| 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 | cheatsheet.txt | 25 C: Ordering is cumulative
26 P: Ordering propagates
29 Y: Provides ordering
30 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.
159 Ordering can be extended to CPUs not holding the lock by careful use
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.
[all …]
|
| /Linux-v5.10/tools/include/linux/ |
| D | refcount.h | 15 * Memory ordering rules are slightly relaxed wrt regular atomic_t functions
18 * The increments are fully relaxed; these will not provide ordering. The
20 * reference count on will provide the ordering. For locked data structures,
36 * Note that the allocator is responsible for ordering things between free()
71 * Provides no memory ordering, it is assumed the caller has guaranteed the
104 * Provides no memory ordering, it is assumed the caller already has a
116 * Provides release memory ordering, such that prior loads and stores are done
|
| D | compiler.h | 161 * particular ordering. One way to make the compiler aware of ordering is to
173 * mutilate accesses that either do not require ordering or that interact
175 * required ordering.
|
| /Linux-v5.10/Documentation/RCU/Design/Memory-Ordering/ |
| D | Tree-RCU-Memory-Ordering.rst | 2 A Tour Through TREE_RCU's Grace-Period Memory Ordering
13 grace-period memory ordering guarantee is provided.
15 What Is Tree RCU's Grace Period Memory Ordering Guarantee?
18 RCU grace periods provide extremely strong memory-ordering guarantees
46 Tree RCU Grace Period Memory Ordering Building Blocks
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.
[all …]
|
| /Linux-v5.10/arch/mips/include/asm/ |
| D | sync.h | 16 * 2) Ordering barriers, which only ensure that affected memory operations
20 * Ordering barriers can be more efficient than completion barriers, since:
22 * a) Ordering barriers only require memory access instructions which preceed
31 * b) Multiple variants of ordering barrier are provided which allow the
35 * barrier & don't care about the ordering of loads then the 'wmb'
36 * ordering barrier can be used. Limiting the barrier's effects to stores
57 * we're satisfied that lightweight ordering barriers defined by MIPSr6 are
65 * ...except on Cavium Octeon CPUs, which have been using the 'wmb' ordering
153 * Some Cavium Octeon CPUs suffer from a bug that causes a single wmb ordering
|
| /Linux-v5.10/include/asm-generic/ |
| D | rwonce.h | 6 * particular ordering. One way to make the compiler aware of ordering is to
16 * mutilate accesses that either do not require ordering or that interact
18 * required ordering.
|
| D | barrier.h | 24 * Force strict CPU ordering. And yes, this is required on UP too when we're
191 * smp_acquire__after_ctrl_dep() - Provide ACQUIRE ordering after a control dependency
204 * smp_cond_load_relaxed() - (Spin) wait for cond with no ordering guarantees
228 * smp_cond_load_acquire() - (Spin) wait for cond with ACQUIRE ordering
|
| /Linux-v5.10/tools/perf/pmu-events/arch/x86/goldmont/ |
| D | memory.json | 26 …e clears due to memory ordering issues. This occurs when a snoop request happens and the machine …
32 "BriefDescription": "Machine clears due to memory ordering issue"
|
| /Linux-v5.10/tools/perf/pmu-events/arch/x86/goldmontplus/ |
| D | memory.json | 28 …e clears due to memory ordering issues. This occurs when a snoop request happens and the machine …
36 "BriefDescription": "Machine clears due to memory ordering issue"
|
| /Linux-v5.10/fs/jffs2/ |
| D | README.Locking | 37 Ordering constraints: See f->sem.
62 Ordering constraints:
67 No ordering rules have been made for doing so.
115 Ordering constraints:
147 Ordering constraints:
168 Ordering constraints:
|
| /Linux-v5.10/drivers/staging/rtl8723bs/include/ |
| D | basic_types.h | 40 /* Convert little data endian to host ordering */
51 /* Read le16 data from memory and convert to host ordering */
62 /* Write le data to memory in host ordering */
100 * Return 4-byte value in host byte ordering from
113 /* 4-byte value in host byte ordering. */
134 /* and return the result in 4-byte value in host byte ordering. */
|
| /Linux-v5.10/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 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/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
220 Ordering of these devices during suspend/resume is determined by the
245 correct suspend/resume and shutdown ordering between parent and child,
|
| /Linux-v5.10/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-v5.10/drivers/staging/rtl8188eu/include/ |
| D | basic_types.h | 25 /* Convert little data endian to host ordering */
60 * Return 4-byte value in host byte ordering from
72 * value to host byte ordering.
92 * and return the result in 4-byte value in host byte ordering.
|
| /Linux-v5.10/tools/perf/pmu-events/arch/x86/silvermont/ |
| D | memory.json | 3 …: "This event counts the number of times that pipeline was cleared due to memory ordering issues.",
9 "BriefDescription": "Stalls due to Memory ordering"
|
| /Linux-v5.10/arch/riscv/include/asm/ |
| D | barrier.h | 20 /* These barriers need to enforce ordering on both devices or memory. */
25 /* These barriers do not need to enforce ordering on devices, just memory. */
59 * way we can take advantage of that here because the ordering is only enforced
|
| /Linux-v5.10/Documentation/dev-tools/ |
| D | kcsan.rst | 201 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/RCU/ |
| D | index.rst | 28 Design/Memory-Ordering/Tree-RCU-Memory-Ordering
|
| /Linux-v5.10/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?
|
12345678910>>...35
