Lines Matching refs:accesses
77 - Acquires vs memory accesses.
78 - Acquires vs I/O accesses.
158 The set of accesses as seen by the memory system in the middle can be arranged
231 (*) On any given CPU, dependent memory accesses will be issued in order, with
291 (*) It _must_ be assumed that overlapping memory accesses may be merged or
499 an ACQUIRE on a given variable, all memory accesses preceding any prior
501 words, within a given variable's critical section, all accesses of all
530 (*) There is no guarantee that any of the memory accesses specified before a
533 access queue that accesses of the appropriate type may not cross.
538 of the first CPU's accesses occur, but see the next point:
541 from a second CPU's accesses, even _if_ the second CPU uses a memory
546 hardware[*] will not reorder the memory accesses. CPU cache coherency
853 compiler cannot reorder volatile accesses and also cannot reorder
1419 agree on the combined order of multiple accesses.
1426 on the combined order of the accesses. For example, switching to C code
1523 compiler from moving the memory accesses either side of it to the other side:
1530 accesses flagged by the READ_ONCE() or WRITE_ONCE().
1534 (*) Prevents the compiler from reordering accesses following the
1535 barrier() to precede any accesses preceding the barrier().
1562 accesses from multiple CPUs to a single variable.
1670 (*) The compiler is within its rights to reorder memory accesses unless
1714 be interrupted by something that also accesses 'flag' and 'msg',
1768 multiple smaller accesses. For example, given an architecture having
1850 and will order overlapping accesses correctly with respect to itself.
1859 however, be used to control MMIO effects on accesses through relaxed memory I/O
1953 See the subsection "Acquires vs I/O accesses" for more information.
2022 the two accesses can themselves then cross:
2082 anything at all - especially with respect to I/O accesses - unless combined
2259 separate data accesses. Thus the above sleeper ought to do:
2307 Then there is no guarantee as to what order CPU 3 will see the accesses to *A
2325 Under certain circumstances (especially involving NUMA), I/O accesses within
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
2525 make the right memory accesses in exactly the right order.
2528 in that the carefully sequenced accesses in the driver code won't reach the
2530 efficient to reorder, combine or merge accesses - something that would cause
2534 routines - such as inb() or writel() - which know how to make such accesses
2583 If ordering rules are relaxed, it must be assumed that accesses done inside an
2585 accesses performed in an interrupt - and vice versa - unless implicit or
2588 Normally this won't be a problem because the I/O accesses done inside such
2658 respect to normal memory accesses (e.g. DMA buffers) nor do they guarantee
2660 required, an mmiowb() barrier can be used. Note that relaxed accesses to
2745 accesses to be performed. The core may place these in the queue in any order
2750 accesses cross from the CPU side of things to the memory side of things, and
2757 [!] MMIO or other device accesses may bypass the cache system. This depends on
2893 cachelets for normal memory accesses. The semantics of the Alpha removes the
2928 Amongst these properties is usually the fact that such accesses bypass the
2929 caching entirely and go directly to the device buses. This means MMIO accesses
2930 may, in effect, overtake accesses to cached memory that were emitted earlier.
2970 (*) the order of the memory accesses may be rearranged to promote better use
2974 memory or I/O hardware that can do batched accesses of adjacent locations,
2992 _own_ accesses appear to be correctly ordered, without the need for a memory
3011 accesses: