Lines Matching refs:load
23 - Read memory barriers vs load speculation.
163 Note that CPU 2 will never try and load C into D because the CPU will load P
164 into Q before issuing the load of *Q.
364 of the first (eg: the first load retrieves the address to which the second
365 load will be directed), a data dependency barrier would be required to
366 make sure that the target of the second load is updated before the address
367 obtained by the first load is accessed.
376 under consideration guarantees that for any load preceding it, if that
377 load touches one of a sequence of stores from another CPU, then by the
379 touched by the load will be perceptible to any loads issued after the data
385 [!] Note that the first load really has to have a _data_ dependency and
386 not a control dependency. If the address for the second load is dependent
387 on the first load, but the dependency is through a conditional rather than
396 (3) Read (or load) memory barriers.
543 between the address load and the data load:
595 A load-load control dependency requires a full read memory barrier, not
608 the load from b as having happened before the load from a. In such a
618 for load-store control dependencies, as in the following example:
627 READ_ONCE(), the compiler might combine the load from 'a' with other
660 WRITE_ONCE(b, p); /* BUG: No ordering vs. load from a!!! */
669 Now there is no conditional between the load from 'a' and the store to
722 between the load from variable 'a' and the store to variable 'b'. It is
729 BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */
758 the compiler to actually emit code for a given load, it does not force
808 between the prior load and the subsequent store, and this
809 conditional must involve the prior load. If the compiler is able
964 The load of X holds ---> \ | X->9 |------>| |
971 In the above example, CPU 2 perceives that B is 7, despite the load of *C
974 If, however, a data dependency barrier were to be placed between the load of C
975 and the load of *C (ie: B) on CPU 2:
1051 If, however, a read barrier were to be placed between the load of B and the
1052 load of A on CPU 2:
1088 contained a load of A either side of the read barrier:
1097 LOAD A [first load of A]
1099 LOAD A [second load of A]
1101 Even though the two loads of A both occur after the load of B, they may both
1153 The guarantee is that the second load will always come up with A == 1 if the
1154 load of B came up with B == 2. No such guarantee exists for the first load of
1161 Many CPUs speculate with loads: that is they see that they will need to load an
1163 other loads, and so do the load in advance - even though they haven't actually
1165 actual load instruction to potentially complete immediately because the CPU
1169 branch circumvented the load - in which case it can discard the value or just
1200 load:
1269 Suppose that CPU 2's load from X returns 1 and its load from Y returns 0.
1270 This indicates that CPU 2's load from X in some sense follows CPU 1's
1271 store to X and that CPU 2's load from Y in some sense preceded CPU 3's
1272 store to Y. The question is then "Can CPU 3's load from X return 0?"
1274 Because CPU 2's load from X in some sense came after CPU 1's store, it
1275 is natural to expect that CPU 3's load from X must therefore return 1.
1276 This expectation is an example of transitivity: if a load executing on
1277 CPU A follows a load from the same variable executing on CPU B, then
1278 CPU A's load must either return the same value that CPU B's load did,
1282 transitivity. Therefore, in the above example, if CPU 2's load from X
1283 returns 1 and its load from Y returns 0, then CPU 3's load from X must
1298 legal for CPU 2's load from X to return 1, its load from Y to return 0,
1299 and CPU 3's load from X to return 0.
1346 (*) Within a loop, forces the compiler to load the variables used
1421 (*) The compiler is within its rights to omit a load entirely if it knows
1433 gets rid of a load and a branch. The problem is that the compiler
1451 the code into near-nonexistence. (It will still load from the
1573 with a single memory-reference instruction, prevents "load tearing"
1592 Use of packed structures can also result in load and store tearing,
1611 load tearing on 'foo1.b' and store tearing on 'foo2.b'. READ_ONCE()
1646 to issue the loads in the correct order (eg. `a[b]` would have to load
1649 (eg. is equal to 1) and load a before b (eg. tmp = a[1]; if (b != 1)
2022 wake_up(); load from Y sees 1, no memory barrier
2023 load from X might see 0
2025 In contrast, if a wakeup does occur, CPU 2's load from X would be guaranteed
2179 Furthermore, following a store by a load from the same device obviates the need
2180 for the mmiowb(), because the load forces the store to complete before the load
2478 sections will include synchronous load operations on strictly ordered I/O
2529 deferral if it so wishes; to flush a store, a load from the same location
2530 is preferred[*], but a load from the same device or from configuration
2533 [*] NOTE! attempting to load from the same location as was written to may
2581 ultimate effect. For example, if two adjacent instructions both load an
2625 Although any particular load or store may not actually appear outside of the
2633 generate load and store operations which then go into the queue of memory
2694 displace a dirty cacheline or to do a speculative load;
2873 (Where "LOAD {*C,*D}" is a combined load)