Lines Matching refs:ordering
87 (*) Assumed minimum execution ordering model.
137 abstract CPU, memory operation ordering is very relaxed, and a CPU may actually
365 ordering over the memory operations on either side of the barrier.
387 A write barrier is a partial ordering on stores only; it is not required
407 An address-dependency barrier is a partial ordering on interdependent
421 showing the ordering constraints.
445 A read barrier is a partial ordering on loads only; it is not required to
462 A general memory barrier is a partial ordering over both loads and stores.
653 of dependency ordering is to -prevent- writes to the data structure, along
656 naturally occurring ordering prevents such records from being lost.
659 Note well that the ordering provided by an address dependency is local to
703 However, stores are not speculated. This means that ordering -is- provided
716 Either can result in highly counterintuitive effects on ordering.
728 It is tempting to try to enforce ordering on identical stores on both
747 WRITE_ONCE(b, 1); /* BUG: No ordering vs. load from a!!! */
760 Therefore, if you need ordering in this example, you need explicit
773 ordering is guaranteed only when the stores differ, for example:
808 Given this transformation, the CPU is not required to respect the ordering
812 relying on this ordering, you should make sure that MAX is greater than
858 WRITE_ONCE(c, 1); /* BUG: No ordering against the read from 'a'. */
860 It is tempting to argue that there in fact is ordering because the
882 Note well that the ordering provided by a control dependency is local
890 However, they do -not- guarantee any other sort of ordering:
892 later anything. If you need these other forms of ordering,
909 away the ordering. Careful use of READ_ONCE() and WRITE_ONCE()
1172 then the partial ordering imposed by CPU 1 will be perceived correctly by CPU
1366 Multicopy atomicity is a deeply intuitive notion about ordering that is
1430 but can also generate additional ordering that can ensure that -all-
1432 chain of release-acquire pairs do not provide this additional ordering,
1479 However, the ordering provided by a release-acquire chain is local
1500 In particular, it simply reads from its argument with ordering. It does
1509 To reiterate, if your code requires full ordering of all operations,
1842 barrier. Address dependencies do not impose any additional compiler ordering.
1859 [!] Note that SMP memory barriers _must_ be used to control the ordering of
1911 These are for use with consistent memory to guarantee the ordering
1961 in addition to the ordering done by wmb().
1964 to ensure read ordering.
2098 Locks and semaphores may not provide any guarantee of ordering on UP compiled
2254 In terms of memory ordering, these functions all provide the same guarantees of
2306 that does affect memory access ordering on other CPUs, within the context of
2455 CPU, that CPU's dependency ordering logic will take care of everything else.
2487 memory barriers are required to enforce ordering.
2520 address register if ordering rules are sufficiently relaxed:
2525 If ordering rules are relaxed, it must be assumed that accesses done inside an
2537 likely, then interrupt-disabling locks should be used to guarantee ordering.
2549 series of accessor functions that provide various degrees of ordering
2557 ioremap()), the ordering guarantees are as follows:
2597 The ordering properties of __iomem pointers obtained with non-default
2605 ordering guarantees. Specifically, they do not guarantee ordering with
2616 capable of performing DMA. Consequently, they provide only the ordering
2627 internal virtual memory mapping, the portable ordering guarantees
2635 not part of the portable ordering semantics.
2639 As above, the insX() and outsX() accessors provide the same ordering
2825 (*) the CPU's data cache may affect the ordering, and while cache-coherency