s390/barrier: avoid serialization in [smp_]rmb and [smp_]wmb
authorChristian Borntraeger <borntraeger@de.ibm.com>
Fri, 11 Sep 2015 14:32:24 +0000 (16:32 +0200)
committerMartin Schwidefsky <schwidefsky@de.ibm.com>
Wed, 14 Oct 2015 12:32:01 +0000 (14:32 +0200)
commit1afc82aee45c118dc8026d54a230e75ff6baee66
treeb478e20ec24f9b55ee3471978213513cb426bc4f
parent33b5881d11c5d852662efb764f5054347296a062
s390/barrier: avoid serialization in [smp_]rmb and [smp_]wmb

The principles of operation says:

The storage-operand fetch references of one instruction
occur after those of all preceding instructions and
before those of subsequent instructions, as observed
by other CPUs and by channel programs.
[...]
The CPU may fetch the operands of instructions before the
instructions are executed.
[...]
The CPU may delay placing results in storage.
[...]
the results of one instruction are placed in storage after
the results of all preceding instructions have been placed
in storage and before any results of the succeeding
instructions are stored, as observed by other CPUs and by
the channel subsystem.

which boils down to:
- reads are in order
- writes are in order
- reads can happen earlier
- writes can happen later

By definition (see memory-barrier.txt) read barriers orders
reads vs reads and write barriers orders writes agains writes.
but neither of these orders reads vs. writes.

That means we can implement smp_wmb,smp_rmb,wmb and rmb as
simple compiler barriers. To avoid reviewing all driver code
for correct barrier usage we keep dma_[rw]mb as serialization
for now.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
arch/s390/include/asm/barrier.h