Lines Matching full:accesses
76 - Acquires vs memory accesses.
156 The set of accesses as seen by the memory system in the middle can be arranged
229 (*) On any given CPU, dependent memory accesses will be issued in order, with
289 (*) It _must_ be assumed that overlapping memory accesses may be merged or
495 ACQUIRE on a given variable, all memory accesses preceding any prior
497 words, within a given variable's critical section, all accesses of all
526 (*) There is no guarantee that any of the memory accesses specified before a
529 access queue that accesses of the appropriate type may not cross.
534 of the first CPU's accesses occur, but see the next point:
537 from a second CPU's accesses, even _if_ the second CPU uses a memory
542 hardware[*] will not reorder the memory accesses. CPU cache coherency
849 compiler cannot reorder volatile accesses and also cannot reorder
1415 agree on the combined order of multiple accesses.
1422 on the combined order of the accesses. For example, switching to C code
1517 compiler from moving the memory accesses either side of it to the other side:
1524 accesses flagged by the READ_ONCE() or WRITE_ONCE().
1528 (*) Prevents the compiler from reordering accesses following the
1529 barrier() to precede any accesses preceding the barrier().
1556 accesses from multiple CPUs to a single variable.
1664 (*) The compiler is within its rights to reorder memory accesses unless
1708 be interrupted by something that also accesses 'flag' and 'msg',
1762 multiple smaller accesses. For example, given an architecture having
1844 and will order overlapping accesses correctly with respect to itself.
1853 however, be used to control MMIO effects on accesses through relaxed memory I/O
2019 the two accesses can themselves then cross:
2079 anything at all - especially with respect to I/O accesses - unless combined
2256 separate data accesses. Thus the above sleeper ought to do:
2289 ACQUIRES VS MEMORY ACCESSES
2304 Then there is no guarantee as to what order CPU 3 will see the accesses to *A
2425 In this case, the barrier makes a guarantee that all memory accesses before the
2426 barrier will appear to happen before all the memory accesses after the barrier
2428 the memory accesses before the barrier will be complete by the time the barrier
2453 make the right memory accesses in exactly the right order.
2456 in that the carefully sequenced accesses in the driver code won't reach the
2458 efficient to reorder, combine or merge accesses - something that would cause
2462 routines - such as inb() or writel() - which know how to make such accesses
2504 If ordering rules are relaxed, it must be assumed that accesses done inside an
2506 accesses performed in an interrupt - and vice versa - unless implicit or
2509 Normally this won't be a problem because the I/O accesses done inside such
2523 Interfacing with peripherals via I/O accesses is deeply architecture and device
2538 1. All readX() and writeX() accesses to the same peripheral are ordered
2539 with respect to each other. This ensures that MMIO register accesses
2579 generally be relied upon for accesses to these types of mappings.
2585 respect to locking, normal memory accesses or delay() loops (i.e.
2587 respect to other accesses from the same CPU thread to the same
2708 accesses to be performed. The core may place these in the queue in any order
2713 accesses cross from the CPU side of things to the memory side of things, and
2720 [!] MMIO or other device accesses may bypass the cache system. This depends on
2753 Amongst these properties is usually the fact that such accesses bypass the
2754 caching entirely and go directly to the device buses. This means MMIO accesses
2755 may, in effect, overtake accesses to cached memory that were emitted earlier.
2795 (*) the order of the memory accesses may be rearranged to promote better use
2799 memory or I/O hardware that can do batched accesses of adjacent locations,
2817 _own_ accesses appear to be correctly ordered, without the need for a memory
2836 accesses:
2958 Chapter 5: Memory Accesses and Cacheability