From: Will Deacon <will.deacon@arm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Arnd Bergmann <arnd@arndb.de>,
corbet@lwn.net,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Sinan Kaya <okaya@codeaurora.org>, Jason Gunthorpe <jgg@ziepe.ca>,
peterz@infradead.org, David Laight <David.Laight@aculab.com>,
Oliver <oohall@gmail.com>,
Alexander Duyck <alexander.h.duyck@redhat.com>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
mingo@redhat.com
Subject: Re: RFC on writel and writel_relaxed
Date: Tue, 27 Mar 2018 10:57:46 +0100 [thread overview]
Message-ID: <20180327095745.GB29373@arm.com> (raw)
In-Reply-To: <1522141019.7364.43.camel@kernel.crashing.org>
[+ locking/ordering/docs people]
On Tue, Mar 27, 2018 at 07:56:59PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote:
> > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote:
> > > > On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote:
> > >
> > > I even see patches adding wmb() based on actual observed memory
> > > corruption during testing on Intel:
> > >
> > > https://patchwork.kernel.org/patch/10177207/
> > >
> > > So you think all of this is unnecessary and writel is totally strongly
> > > ordered, even on multi-socket Intel?
> >
> > This example adds a wmb() between two writes to a coherent DMA
> > area, it is definitely required there.
>
> Ah you are right, I incorrectly assumed that the "prod_db" function was
> an MMIO. So we do NOT have a counter example where wmb is needed on
> x86, pfiew ! :-)
>
> > I'm pretty sure I've never seen
> > any bug reports pointing to a missing wmb() between memory
> > and MMIO write accesses, but if you remember seeing them in the
> > list, maybe you can look again for some evidence of something going
> > wrong on x86 without it?
>
> The interesting thing is that we do seem to have a whole LOT of these
> spurrious wmb before writel all over the tree, I suspect because of
> that incorrect recommendation in memory-barriers.txt.
>
> We should fix that.
Patch below. Thoughts?
Will
--->8
>From db0daeaf94f0f6232f8206fc07a74211324b11d9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon@arm.com>
Date: Tue, 27 Mar 2018 10:49:58 +0100
Subject: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering
example
The section of memory-barriers.txt that describes the dma_Xmb() barriers
has an incorrect example claiming that a wmb() is required after writing
to coherent memory in order for those writes to be visible to a device
before a subsequent MMIO access using writel() can reach the device.
In fact, this ordering guarantee is provided (at significant cost on some
architectures such as arm and power) by writel, so the wmb() is not
necessary. writel_relaxed exists for cases where this ordering is not
required.
Fix the example and update the text to make this clearer.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Reported-by: Sinan Kaya <okaya@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
Documentation/memory-barriers.txt | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index a863009849a3..2556b4b0e6f9 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1909,9 +1909,6 @@ There are some more advanced barrier functions:
/* assign ownership */
desc->status = DEVICE_OWN;
- /* force memory to sync before notifying device via MMIO */
- wmb();
-
/* notify device of new descriptors */
writel(DESC_NOTIFY, doorbell);
}
@@ -1919,11 +1916,16 @@ There are some more advanced barrier functions:
The dma_rmb() allows us guarantee the device has released ownership
before we read the data from the descriptor, and the dma_wmb() allows
us to guarantee the data is written to the descriptor before the device
- can see it now has ownership. The wmb() is needed to guarantee that the
- cache coherent memory writes have completed before attempting a write to
- the cache incoherent MMIO region.
-
- See Documentation/DMA-API.txt for more information on consistent memory.
+ can see it now has ownership. Note that, when using writel(), a prior
+ wmb() is not needed to guarantee that the cache coherent memory writes
+ have completed before writing to the cache incoherent MMIO region.
+ If this ordering between incoherent MMIO and coherent memory regions
+ is not required, writel_relaxed() can be used instead and is significantly
+ cheaper on some weakly-ordered architectures.
+
+ See the subsection "Kernel I/O barrier effects" for more information on
+ relaxed I/O accessors and the Documentation/DMA-API.txt file for more
+ information on consistent memory.
MMIO WRITE BARRIER
--
2.1.4
next prev parent reply other threads:[~2018-03-27 9:57 UTC|newest]
Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 3:07 RFC on writel and writel_relaxed Sinan Kaya
2018-03-21 3:40 ` Oliver
2018-03-21 13:53 ` Sinan Kaya
2018-03-21 13:58 ` Sinan Kaya
2018-03-26 13:43 ` Arnd Bergmann
2018-03-26 16:00 ` Sinan Kaya
2018-03-21 14:35 ` David Laight
2018-03-21 15:04 ` Sinan Kaya
2018-03-22 5:24 ` Oliver
2018-03-22 8:20 ` Gabriel Paubert
2018-03-22 9:25 ` Oliver
2018-03-22 11:25 ` Gabriel Paubert
2018-03-22 10:37 ` David Laight
2018-03-22 4:24 ` Benjamin Herrenschmidt
2018-03-22 10:15 ` Oliver
2018-03-22 13:52 ` Benjamin Herrenschmidt
2018-03-22 17:51 ` Sinan Kaya
2018-03-23 0:16 ` Benjamin Herrenschmidt
2018-03-23 13:42 ` Sinan Kaya
2018-03-24 1:22 ` Benjamin Herrenschmidt
2018-03-24 15:06 ` Sinan Kaya
2018-03-26 11:44 ` Will Deacon
2018-03-26 12:11 ` okaya
2018-03-26 12:42 ` Sinan Kaya
2018-03-23 16:35 ` Jason Gunthorpe
2018-03-24 1:23 ` Benjamin Herrenschmidt
2018-03-26 11:08 ` David Laight
2018-03-26 16:54 ` Jason Gunthorpe
2018-03-26 19:44 ` Arnd Bergmann
2018-03-26 20:25 ` Jason Gunthorpe
2018-03-26 20:43 ` Arnd Bergmann
2018-03-26 21:09 ` Jason Gunthorpe
2018-03-26 21:30 ` Arnd Bergmann
2018-03-26 21:46 ` Sinan Kaya
2018-03-26 22:01 ` Benjamin Herrenschmidt
2018-03-26 22:08 ` Sinan Kaya
2018-03-26 22:28 ` Benjamin Herrenschmidt
2018-03-26 22:27 ` Jason Gunthorpe
2018-03-26 22:36 ` Benjamin Herrenschmidt
2018-03-26 22:42 ` Benjamin Herrenschmidt
2018-03-26 22:50 ` Jason Gunthorpe
2018-03-26 23:59 ` Benjamin Herrenschmidt
2018-03-27 1:39 ` Jason Gunthorpe
2018-03-27 7:56 ` Arnd Bergmann
2018-03-27 8:56 ` Benjamin Herrenschmidt
2018-03-27 9:44 ` Arnd Bergmann
2018-03-27 10:00 ` Will Deacon
2018-03-27 11:23 ` Benjamin Herrenschmidt
2018-03-27 12:22 ` okaya
2018-03-27 14:12 ` Jason Gunthorpe
2018-03-27 21:27 ` Benjamin Herrenschmidt
2018-03-27 9:57 ` Will Deacon [this message]
2018-03-27 10:05 ` Arnd Bergmann
2018-03-27 10:09 ` Will Deacon
2018-03-27 10:53 ` Arnd Bergmann
2018-03-27 11:02 ` Will Deacon
2018-03-27 11:05 ` Arnd Bergmann
2018-03-27 11:25 ` Benjamin Herrenschmidt
2018-03-27 13:20 ` David Laight
2018-03-27 13:46 ` Sinan Kaya
2018-03-27 14:36 ` Will Deacon
2018-03-27 21:29 ` Benjamin Herrenschmidt
2018-03-28 8:53 ` Will Deacon
2018-03-28 9:00 ` David Laight
2018-03-28 9:09 ` Will Deacon
2018-03-28 9:56 ` Benjamin Herrenschmidt
2018-03-28 9:50 ` Benjamin Herrenschmidt
2018-03-28 9:55 ` Arnd Bergmann
2018-03-28 10:01 ` Benjamin Herrenschmidt
2018-03-28 10:13 ` Will Deacon
2018-03-28 16:57 ` Jason Gunthorpe
2018-03-29 9:19 ` Will Deacon
2018-03-29 14:45 ` Jason Gunthorpe
2018-03-29 14:58 ` David Laight
2018-03-29 16:40 ` Jason Gunthorpe
2018-03-27 21:24 ` Benjamin Herrenschmidt
2018-03-27 11:21 ` Benjamin Herrenschmidt
2018-03-27 9:42 ` Will Deacon
2018-03-27 11:20 ` Benjamin Herrenschmidt
2018-03-27 11:24 ` Will Deacon
2018-03-27 14:24 ` Jason Gunthorpe
2018-03-27 14:16 ` Jason Gunthorpe
2018-03-26 22:00 ` Benjamin Herrenschmidt
2018-03-27 14:46 ` Sinan Kaya
2018-03-27 15:01 ` Jose Abreu
2018-03-27 15:10 ` Will Deacon
2018-03-27 18:54 ` Alexander Duyck
2018-03-27 19:54 ` Arnd Bergmann
2018-03-27 20:46 ` Arnd Bergmann
2018-03-27 21:33 ` Benjamin Herrenschmidt
2018-03-28 0:39 ` Linus Torvalds
2018-03-28 1:03 ` Benjamin Herrenschmidt
2018-03-28 2:51 ` Linus Torvalds
2018-03-28 3:24 ` Sinan Kaya
2018-03-28 4:41 ` Benjamin Herrenschmidt
2018-03-28 6:14 ` Linus Torvalds
2018-03-28 11:41 ` okaya
2018-03-28 15:13 ` Benjamin Herrenschmidt
2018-03-28 15:55 ` David Miller
2018-03-28 16:23 ` Nicholas Piggin
2018-03-28 21:31 ` Benjamin Herrenschmidt
2018-03-28 22:09 ` Nicholas Piggin
2018-03-29 9:20 ` Will Deacon
2018-03-29 13:56 ` Sinan Kaya
2018-03-29 14:04 ` David Miller
2018-03-29 16:29 ` Arnd Bergmann
2018-03-29 16:59 ` Sinan Kaya
2018-03-30 1:40 ` Benjamin Herrenschmidt
2018-04-02 13:01 ` Sinan Kaya
2018-03-28 4:33 ` Benjamin Herrenschmidt
2018-03-28 6:26 ` Linus Torvalds
2018-03-28 6:42 ` Benjamin Herrenschmidt
2018-03-28 6:53 ` Linus Torvalds
2018-03-28 6:56 ` Benjamin Herrenschmidt
2018-03-28 7:11 ` Arnd Bergmann
2018-03-28 7:42 ` Benjamin Herrenschmidt
2018-03-28 9:07 ` Will Deacon
2018-03-28 9:56 ` Benjamin Herrenschmidt
2018-03-28 10:13 ` Aw: " Lino Sanfilippo
2018-03-28 10:20 ` Benjamin Herrenschmidt
2018-03-28 11:30 ` David Laight
2018-03-28 15:12 ` Benjamin Herrenschmidt
2018-03-28 16:16 ` David Laight
2018-03-28 1:21 ` Benjamin Herrenschmidt
2018-03-27 21:35 ` Benjamin Herrenschmidt
2018-03-26 21:26 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2018-03-27 21:54 Alexander Duyck
2018-03-27 22:35 ` Sinan Kaya
2018-03-27 23:43 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180327095745.GB29373@arm.com \
--to=will.deacon@arm.com \
--cc=David.Laight@aculab.com \
--cc=alexander.h.duyck@redhat.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=corbet@lwn.net \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=okaya@codeaurora.org \
--cc=oohall@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).