Lines Matching refs:barrier
29 particular barrier, and
34 for any particular barrier, but if the architecture provides less than
37 Note also that it is possible that a barrier may be a no-op for an
38 architecture because the way that arch works renders an explicit barrier
53 - Varieties of memory barrier.
57 - SMP barrier pairing.
58 - Examples of memory barrier sequences.
64 - Compiler barrier.
66 - MMIO write barrier.
75 (*) Inter-CPU acquiring barrier effects.
87 (*) Kernel I/O barrier effects.
241 emits a memory-barrier instruction, so that a DEC Alpha CPU will
367 ordering over the memory operations on either side of the barrier.
384 A write memory barrier gives a guarantee that all the STORE operations
385 specified before the barrier will appear to happen before all the STORE
386 operations specified after the barrier with respect to the other
389 A write barrier is a partial ordering on stores only; it is not required
393 memory system as time progresses. All stores _before_ a write barrier
394 will occur _before_ all the stores after the write barrier.
397 dependency barriers; see the "SMP barrier pairing" subsection.
402 A data dependency barrier is a weaker form of read barrier. In the case
405 load will be directed), a data dependency barrier would be required to
409 A data dependency barrier is a partial ordering on interdependent loads
415 considered can then perceive. A data dependency barrier issued by the CPU
418 time the barrier completes, the effects of all the stores prior to that
420 dependency barrier.
422 See the "Examples of memory barrier sequences" subsection for diagrams
429 a full read barrier or better is required. See the "Control dependencies"
433 write barriers; see the "SMP barrier pairing" subsection.
438 A read barrier is a data dependency barrier plus a guarantee that all the
439 LOAD operations specified before the barrier will appear to happen before
440 all the LOAD operations specified after the barrier with respect to the
443 A read barrier is a partial ordering on loads only; it is not required to
450 see the "SMP barrier pairing" subsection.
455 A general memory barrier gives a guarantee that all the LOAD and STORE
456 operations specified before the barrier will appear to happen before all
457 the LOAD and STORE operations specified after the barrier with respect to
460 A general memory barrier is a partial ordering over both loads and stores.
470 This acts as a one-way permeable barrier. It guarantees that all memory
486 This also acts as a one-way permeable barrier. It guarantees that all
496 for other sorts of memory barrier (but note the exceptions mentioned in
497 the subsection "MMIO write barrier"). In addition, a RELEASE+ACQUIRE
498 pair is -not- guaranteed to act as a full memory barrier. However, after
509 RELEASE variants in addition to fully-ordered and relaxed (no barrier
531 memory barrier will be _complete_ by the completion of a memory barrier
532 instruction; the barrier can be considered to draw a line in that CPU's
535 (*) There is no guarantee that issuing a memory barrier on one CPU will have
542 barrier, unless the first CPU _also_ uses a matching memory barrier (see
547 mechanisms should propagate the indirect effects of a memory barrier
575 <write barrier>
595 To deal with this, a data dependency barrier or better must be inserted
602 <write barrier>
605 <data dependency barrier>
622 A data-dependency barrier is not required to order dependent writes
634 <write barrier>
639 Therefore, no data-dependency barrier is required to order the read into
641 even without a data-dependency barrier:
657 The data dependency barrier is very important to the RCU system,
673 A load-load control dependency requires a full read memory barrier, not
674 simply a data dependency barrier to make it work correctly. Consider the
679 <data dependency barrier> /* BUG: No data dependency!!! */
691 <read barrier>
725 barrier();
729 barrier();
738 barrier();
802 tempting to add a barrier(), but this does not help. The conditional
803 is gone, and the barrier won't bring it back. Therefore, if you are
892 to use barrier() at beginning of each leg of the "if" statement
895 barrier() law.
927 When dealing with CPU-CPU interactions, certain types of memory barrier should
932 barrier pairs with a release barrier, but both may also pair with other
933 barriers, including of course general barriers. A write barrier pairs
934 with a data dependency barrier, a control dependency, an acquire barrier,
935 a release barrier, a read barrier, or a general barrier. Similarly a
936 read barrier, control dependency, or a data dependency barrier pairs
937 with a write barrier, an acquire barrier, a release barrier, or a
938 general barrier:
943 <write barrier>
945 <read barrier>
953 <write barrier>
955 <data dependency barrier>
963 <general barrier>
971 Basically, the read barrier always has to be there, even though it can be of
974 [!] Note that the stores before the write barrier would normally be expected to
975 match the loads after the read barrier or the data dependency barrier, and vice
982 <write barrier> \ <read barrier>
998 <write barrier>
1015 | | wwwwwwwwwwwwwwww } <--- At this point the write barrier
1017 | | : | E=5 | } barrier to be committed before
1036 <write barrier>
1042 effectively random order, despite the write barrier issued by CPU 1:
1074 If, however, a data dependency barrier were to be placed between the load of C
1082 <write barrier>
1085 <data dependency barrier>
1115 And thirdly, a read barrier acts as a partial order on loads. Consider the
1122 <write barrier>
1128 some effectively random order, despite the write barrier issued by CPU 1:
1151 If, however, a read barrier were to be placed between the load of B and the
1158 <write barrier>
1161 <read barrier>
1181 barrier causes all effects \ +-------+ | |
1188 contained a load of A either side of the read barrier:
1194 <write barrier>
1198 <read barrier>
1221 barrier causes all effects \ +-------+ | |
1228 before the read barrier completes anyway:
1299 Placing a read barrier or a data dependency barrier just before the second
1307 <read barrier>
1311 dependent on the type of barrier used. If there was no change made to the
1374 <general barrier> <read barrier>
1393 The use of a general memory barrier in the example above compensates
1400 that CPU 2's general barrier is removed from the above example, leaving
1407 <data dependency> <read barrier>
1484 the weak memory-barrier instructions used to implement smp_load_acquire()
1512 (*) Compiler barrier.
1516 (*) MMIO write barrier.
1522 The Linux kernel has an explicit compiler barrier function that prevents the
1525 barrier();
1527 This is a general barrier -- there are no read-read or write-write
1528 variants of barrier(). However, READ_ONCE() and WRITE_ONCE() can be
1529 thought of as weak forms of barrier() that affect only the specific
1532 The barrier() function has the following effects:
1535 barrier() to precede any accesses preceding the barrier().
1724 barrier(), or similar primitives.
1726 This effect could also be achieved using barrier(), but READ_ONCE()
1729 indicated memory locations, while with barrier() the compiler must
1836 barrier. Data dependencies do not impose any additional compiler ordering.
1865 There are some more advanced barrier functions:
1870 barrier after it. It isn't guaranteed to insert anything more than a
1871 compiler barrier in a UP compilation.
1936 See the subsection "Kernel I/O barrier effects" for more information on
1944 The Linux kernel also has a special barrier for use with memory-mapped I/O
1949 This is a variation on the mandatory write barrier that causes writes to weakly
2013 locks do not imply any sort of barrier.
2019 An ACQUIRE followed by a RELEASE may not be assumed to be full memory barrier
2037 RELEASE may -not- be assumed to be a full memory barrier.
2040 not imply a full memory barrier. Therefore, the CPU's execution of the
2075 a memory barrier, which will force the earlier unlock operation
2085 See also the section on "Inter-CPU acquiring barrier effects".
2142 A general memory barrier is interpolated automatically by set_current_state()
2150 <general barrier>
2158 which therefore also imply a general memory barrier after setting the state.
2160 interpolate the memory barrier in the right place:
2182 A general memory barrier is executed by wake_up() if it wakes something up.
2183 If it doesn't wake anything up then a memory barrier may or may not be
2184 executed; you must not rely on it. The barrier occurs before the task state
2193 <general barrier> <general barrier>
2199 To repeat, a general memory barrier is guaranteed to be executed by wake_up()
2213 wake_up_process() always executes a general memory barrier. The barrier again
2287 On SMP systems locking primitives give a more substantial form of barrier: one
2488 The way to deal with this is to insert a general SMP memory barrier:
2497 In this case, the barrier makes a guarantee that all memory accesses before the
2498 barrier will appear to happen before all the memory accesses after the barrier
2500 the memory accesses before the barrier will be complete by the time the barrier
2504 compiler barrier, thus making sure the compiler emits the instructions in the
2648 Used with prefetchable I/O memory, an mmiowb() barrier may be required to
2660 required, an mmiowb() barrier can be used. Note that relaxed accesses to
2814 Imagine, then, that two writes are made on the first CPU, with a write barrier
2828 The write memory barrier forces the other CPUs in the system to perceive that
2864 To intervene, we need to interpolate a data dependency barrier or a read
2865 barrier between the loads (which as of v4.15 is supplied unconditionally
2889 Whilst most CPUs do imply a data dependency barrier on the read when a memory
2931 A memory barrier isn't sufficient in such a case, but rather the cache must be
2993 barrier. For instance with the following code:
3037 since, without either a write barrier or an WRITE_ONCE(), it can be
3043 may, without a memory barrier or an READ_ONCE() and WRITE_ONCE(), be
3058 the data dependency barrier really becomes necessary as this synchronises both