Lines Matching refs:ordering
89 (*) Assumed minimum execution ordering model.
139 abstract CPU, memory operation ordering is very relaxed, and a CPU may actually
367 ordering over the memory operations on either side of the barrier.
389 A write barrier is a partial ordering on stores only; it is not required
409 A data dependency barrier is a partial ordering on interdependent loads
423 showing the ordering constraints.
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.
645 of dependency ordering is to -prevent- writes to the data structure, along
648 naturally occurring ordering prevents such records from being lost.
651 Note well that the ordering provided by a data dependency is local to
694 However, stores are not speculated. This means that ordering -is- provided
707 Either can result in highly counterintuitive effects on ordering.
719 It is tempting to try to enforce ordering on identical stores on both
738 WRITE_ONCE(b, 1); /* BUG: No ordering vs. load from a!!! */
751 Therefore, if you need ordering in this example, you need explicit
764 ordering is guaranteed only when the stores differ, for example:
799 Given this transformation, the CPU is not required to respect the ordering
803 relying on this ordering, you should make sure that MAX is greater than
849 WRITE_ONCE(c, 1); /* BUG: No ordering against the read from 'a'. */
851 It is tempting to argue that there in fact is ordering because the
873 Note well that the ordering provided by a control dependency is local
881 However, they do -not- guarantee any other sort of ordering:
883 later anything. If you need these other forms of ordering,
900 away the ordering. Careful use of READ_ONCE() and WRITE_ONCE()
1163 then the partial ordering imposed by CPU 1 will be perceived correctly by CPU
1357 Multicopy atomicity is a deeply intuitive notion about ordering that is
1421 but can also generate additional ordering that can ensure that -all-
1423 chain of release-acquire pairs do not provide this additional ordering,
1470 However, the ordering provided by a release-acquire chain is local
1491 In particular, it simply reads from its argument with ordering. It does
1500 To reiterate, if your code requires full ordering of all operations,
1835 barrier. Data dependencies do not impose any additional compiler ordering.
1852 [!] Note that SMP memory barriers _must_ be used to control the ordering of
1899 These are for use with consistent memory to guarantee the ordering
2064 Locks and semaphores may not provide any guarantee of ordering on UP compiled
2220 In terms of memory ordering, these functions all provide the same guarantees of
2272 that does affect memory access ordering on other CPUs, within the context of
2421 CPU, that CPU's dependency ordering logic will take care of everything else.
2453 memory barriers are required to enforce ordering.
2486 address register if ordering rules are sufficiently relaxed:
2491 If ordering rules are relaxed, it must be assumed that accesses done inside an
2503 likely, then interrupt-disabling locks should be used to guarantee ordering.
2515 series of accessor functions that provide various degrees of ordering
2523 ioremap()), the ordering guarantees are as follows:
2563 The ordering properties of __iomem pointers obtained with non-default
2571 ordering guarantees. Specifically, they do not guarantee ordering with
2582 capable of performing DMA. Consequently, they provide only the ordering
2593 internal virtual memory mapping, the portable ordering guarantees
2601 not part of the portable ordering semantics.
2605 As above, the insX() and outsX() accessors provide the same ordering
2928 (*) the CPU's data cache may affect the ordering, and while cache-coherency