Lines Matching refs:loads

180 perceived by the loads made by another CPU in the same order as the stores were
249  (*) Overlapping loads and stores within a particular CPU will appear to be
277  (*) It _must_not_ be assumed that independent loads and stores will be issued
371 deferral and combination of memory operations; speculative loads; speculative
390      to have any effect on loads.
403      where two loads are performed such that the second depends on the result
409      A data dependency barrier is a partial ordering on interdependent loads
410      only; it is not required to have any effect on stores, independent loads
411      or overlapping loads.
419      touched by the load will be perceptible to any loads issued after the data
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.
705 load from 'a' with other loads from 'a'.  Without the WRITE_ONCE(),
880   (*) Control dependencies can order prior loads against later stores.
882       Not prior loads against later loads, nor prior stores against
885       later loads, smp_mb().
974 match the loads after the read barrier or the data dependency barrier, and vice
1028 loads.  Consider the following sequence of events:
1110 	  subsequent loads                      +-------+       |       |
1114 And thirdly, a read barrier acts as a partial order on loads.  Consider the
1200 Even though the two loads of A both occur after the load of B, they may both
1260 Many CPUs speculate with loads: that is they see that they will need to load an
1262 other loads, and so do the load in advance - even though they haven't actually
1380 CPU 2 executes its load before its store, and CPU 3 loads from Y before
1381 it loads from X.  The question is then "Can CPU 3's load from X return 0?"
1485 subsequent loads in all cases.  This means that cpu3() can see cpu0()'s
1546  (*) The compiler is within its rights to reorder loads and stores
1548      rights to reorder loads to the same variable.  This means that
1563  (*) The compiler is within its rights to merge successive loads from
1759      The compiler can also invent loads.  These are usually less
1762      invented loads.
1802      loads followed by a pair of 32-bit stores.  This would result in
1838 to issue the loads in the correct order (eg. `a[b]` would have to load
2194 If a wakeup does occur, one (at least) of the two loads must see 1.  If, on
2195 the other hand, a wakeup does not occur, both loads might see 0.
2200 the two loads would be guaranteed to see 1.
2224 order multiple stores before the wake-up with respect to loads of those stored
2705 their own loads and stores as if they had happened in program order.
2760  (*) the coherency queue is not flushed by normal loads to lines already
2762      potentially affect those loads.
2815 barrier between the loads (which as of v4.15 is supplied unconditionally
2910  (*) loads are more likely to need to be completed immediately to permit
2914  (*) loads may be done speculatively, and the result discarded should it prove
2917  (*) loads may be done speculatively, leading to the result having been fetched
2923  (*) loads and stores may be combined to improve performance when talking to
2969 where a given CPU might reorder successive loads to the same location.