From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Oliver <oohall@gmail.com> Cc: Sinan Kaya <okaya@codeaurora.org>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>, "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org> Subject: Re: RFC on writel and writel_relaxed Date: Fri, 23 Mar 2018 00:52:02 +1100 [thread overview] Message-ID: <1521726722.16434.312.camel@kernel.crashing.org> (raw) In-Reply-To: <CAOSf1CFv1HHCL3YOVhRn2U=grdNjaQ=A4m3xwxN2Rek1-_TySg@mail.gmail.com> On Thu, 2018-03-22 at 21:15 +1100, Oliver wrote: > On Thu, Mar 22, 2018 at 3:24 PM, Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: > > On Wed, 2018-03-21 at 08:53 -0500, Sinan Kaya wrote: > > > writel_relaxed() needs to have ordering guarantees with respect to the order > > > device observes writes. > > > > Correct. > > > > > x86 has compiler barrier inside the relaxed() API so that code does not > > > get reordered. ARM64 architecturally guarantees device writes to be observed > > > in order. > > > > > > I was hoping that PPC could follow x86 and inject compiler barrier into the > > > relaxed functions. > > > > > > BTW, I have no idea what compiler barrier does on PPC and if > > > > > > wrltel() == compiler barrier() + wrltel_relaxed() > > > > > > can be said. > > > > No, it's not sufficient. Just to clarify ... barrier() is just a compiler barrier, it means the compiler will generate things in the order they are written. This isn't sufficient on archs with an OO memory model, where an actual memory barrier instruction needs to be emited. As for Oliver comments... > > Replacing wmb() + writel() with wmb() + writel_relaxed() will work on > > PPC, it will just not give you a benefit today. > > > > The main problem is that the semantics of writel/writel_relaxed (and > > read versions) aren't very well defined in Linux esp. when it comes > > to different memory types (NC, WC, ...). > > > > I've been wanting to implement the relaxed accessors for a while but > > was battling with this to try to also better support WC, and due to > > other commitments, this somewhat fell down the cracks. > > > > Two options I can think of: > > > > - Just make the _relaxed variants use an eieio instead of a sync, this > > will effectively lift the ordering guarantee vs. cachable storage (and > > thus unlock) and might give a (small) performance improvement. > > Wouldn't we still have the unlock ordering due to the io_sync hack or > are you thinking we should remove that too for the relaxed version? Well, the documentation says we don't care about synchronization vs. locks so we should probably remove it (then we need to make sure mmiowb works, thus sets the flag). > > However, > > we still have the problem that on WC mappings, neither writel nor > > writel_relaxed will effectively allow combining to happen (only raw > > accesses will because on powerpc *all* barriers will break combining). > > Hmm, eieio is only architected to affect CI+G (and WT) so it shouldn't > affect combining > on non-guarded memory. Do most implementations apply it to all CI > accesses anyway? Yes, as far as I know all implementations will stop combining on *any* barrier instruction. > > - Make writel_relaxed() be a simple store without barriers, and > > readl_relaxed() be "eieio, read, eieio", thus allowing write combining > > to happen between successive writel_relaxed on WC space (no change on > > normal NC space) while maintaining the ordering between relaxed reads > > and writes. The flip side is a (slight) increased overhead of > > readl_relaxed. > > Are there many drivers that actually do writeX() on WC space? > memory-barriers.txt > pretty much says that all bets are off and no ordering guarantees can be assumed > when using readX/writeX on prefetchable IO memory. It seems sketchy enough to > give me some pause, but maybe it works fine elsewhere. I don't know whether any does it, but I want to provide a way for a driver to somewhat reliably obtain write combine semantics without having to hand code endian swap and other horrors involved with using __raw_* accessors. So my thinking is to define that the combination of WC + writel_relaxed gives you that, which it does at least on x86 and ARM afaik. Cheers, Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Oliver <oohall@gmail.com> Cc: Sinan Kaya <okaya@codeaurora.org>, "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org> Subject: Re: RFC on writel and writel_relaxed Date: Fri, 23 Mar 2018 00:52:02 +1100 [thread overview] Message-ID: <1521726722.16434.312.camel@kernel.crashing.org> (raw) In-Reply-To: <CAOSf1CFv1HHCL3YOVhRn2U=grdNjaQ=A4m3xwxN2Rek1-_TySg@mail.gmail.com> On Thu, 2018-03-22 at 21:15 +1100, Oliver wrote: > On Thu, Mar 22, 2018 at 3:24 PM, Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: > > On Wed, 2018-03-21 at 08:53 -0500, Sinan Kaya wrote: > > > writel_relaxed() needs to have ordering guarantees with respect to the order > > > device observes writes. > > > > Correct. > > > > > x86 has compiler barrier inside the relaxed() API so that code does not > > > get reordered. ARM64 architecturally guarantees device writes to be observed > > > in order. > > > > > > I was hoping that PPC could follow x86 and inject compiler barrier into the > > > relaxed functions. > > > > > > BTW, I have no idea what compiler barrier does on PPC and if > > > > > > wrltel() == compiler barrier() + wrltel_relaxed() > > > > > > can be said. > > > > No, it's not sufficient. Just to clarify ... barrier() is just a compiler barrier, it means the compiler will generate things in the order they are written. This isn't sufficient on archs with an OO memory model, where an actual memory barrier instruction needs to be emited. As for Oliver comments... > > Replacing wmb() + writel() with wmb() + writel_relaxed() will work on > > PPC, it will just not give you a benefit today. > > > > The main problem is that the semantics of writel/writel_relaxed (and > > read versions) aren't very well defined in Linux esp. when it comes > > to different memory types (NC, WC, ...). > > > > I've been wanting to implement the relaxed accessors for a while but > > was battling with this to try to also better support WC, and due to > > other commitments, this somewhat fell down the cracks. > > > > Two options I can think of: > > > > - Just make the _relaxed variants use an eieio instead of a sync, this > > will effectively lift the ordering guarantee vs. cachable storage (and > > thus unlock) and might give a (small) performance improvement. > > Wouldn't we still have the unlock ordering due to the io_sync hack or > are you thinking we should remove that too for the relaxed version? Well, the documentation says we don't care about synchronization vs. locks so we should probably remove it (then we need to make sure mmiowb works, thus sets the flag). > > However, > > we still have the problem that on WC mappings, neither writel nor > > writel_relaxed will effectively allow combining to happen (only raw > > accesses will because on powerpc *all* barriers will break combining). > > Hmm, eieio is only architected to affect CI+G (and WT) so it shouldn't > affect combining > on non-guarded memory. Do most implementations apply it to all CI > accesses anyway? Yes, as far as I know all implementations will stop combining on *any* barrier instruction. > > - Make writel_relaxed() be a simple store without barriers, and > > readl_relaxed() be "eieio, read, eieio", thus allowing write combining > > to happen between successive writel_relaxed on WC space (no change on > > normal NC space) while maintaining the ordering between relaxed reads > > and writes. The flip side is a (slight) increased overhead of > > readl_relaxed. > > Are there many drivers that actually do writeX() on WC space? > memory-barriers.txt > pretty much says that all bets are off and no ordering guarantees can be assumed > when using readX/writeX on prefetchable IO memory. It seems sketchy enough to > give me some pause, but maybe it works fine elsewhere. I don't know whether any does it, but I want to provide a way for a driver to somewhat reliably obtain write combine semantics without having to hand code endian swap and other horrors involved with using __raw_* accessors. So my thinking is to define that the combination of WC + writel_relaxed gives you that, which it does at least on x86 and ARM afaik. Cheers, Ben.
next prev parent reply other threads:[~2018-03-22 13:52 UTC|newest] Thread overview: 216+ 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 3:40 ` Oliver 2018-03-21 13:53 ` Sinan Kaya 2018-03-21 13:53 ` Sinan Kaya 2018-03-21 13:58 ` Sinan Kaya 2018-03-21 13:58 ` Sinan Kaya 2018-03-26 13:43 ` Arnd Bergmann 2018-03-26 13:43 ` Arnd Bergmann 2018-03-26 16:00 ` Sinan Kaya 2018-03-26 16:00 ` Sinan Kaya 2018-03-21 14:35 ` David Laight 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 8:20 ` Gabriel Paubert 2018-03-22 9:25 ` Oliver 2018-03-22 9:25 ` Oliver 2018-03-22 11:25 ` Gabriel Paubert 2018-03-22 11:25 ` Gabriel Paubert 2018-03-22 10:37 ` David Laight 2018-03-22 10:37 ` David Laight 2018-03-22 4:24 ` Benjamin Herrenschmidt 2018-03-22 4:24 ` Benjamin Herrenschmidt 2018-03-22 10:15 ` Oliver 2018-03-22 10:15 ` Oliver 2018-03-22 13:52 ` Benjamin Herrenschmidt [this message] 2018-03-22 13:52 ` Benjamin Herrenschmidt 2018-03-22 17:51 ` Sinan Kaya 2018-03-22 17:51 ` Sinan Kaya 2018-03-23 0:16 ` Benjamin Herrenschmidt 2018-03-23 0:16 ` Benjamin Herrenschmidt 2018-03-23 13:42 ` Sinan Kaya 2018-03-23 13:42 ` Sinan Kaya 2018-03-24 1:22 ` Benjamin Herrenschmidt 2018-03-24 1:22 ` Benjamin Herrenschmidt 2018-03-24 15:06 ` Sinan Kaya 2018-03-24 15:06 ` Sinan Kaya 2018-03-26 11:44 ` Will Deacon 2018-03-26 11:44 ` Will Deacon 2018-03-26 12:11 ` okaya 2018-03-26 12:11 ` okaya 2018-03-26 12:42 ` Sinan Kaya 2018-03-26 12:42 ` Sinan Kaya 2018-03-23 16:35 ` Jason Gunthorpe 2018-03-23 16:35 ` Jason Gunthorpe 2018-03-24 1:23 ` Benjamin Herrenschmidt 2018-03-24 1:23 ` Benjamin Herrenschmidt 2018-03-26 11:08 ` David Laight 2018-03-26 11:08 ` David Laight 2018-03-26 16:54 ` Jason Gunthorpe 2018-03-26 16:54 ` Jason Gunthorpe 2018-03-26 19:44 ` Arnd Bergmann 2018-03-26 19:44 ` Arnd Bergmann 2018-03-26 20:25 ` Jason Gunthorpe 2018-03-26 20:25 ` Jason Gunthorpe 2018-03-26 20:43 ` Arnd Bergmann 2018-03-26 20:43 ` Arnd Bergmann 2018-03-26 21:09 ` Jason Gunthorpe 2018-03-26 21:09 ` Jason Gunthorpe 2018-03-26 21:30 ` Arnd Bergmann 2018-03-26 21:30 ` Arnd Bergmann 2018-03-26 21:46 ` Sinan Kaya 2018-03-26 21:46 ` Sinan Kaya 2018-03-26 22:01 ` Benjamin Herrenschmidt 2018-03-26 22:01 ` Benjamin Herrenschmidt 2018-03-26 22:08 ` Sinan Kaya 2018-03-26 22:08 ` Sinan Kaya 2018-03-26 22:28 ` Benjamin Herrenschmidt 2018-03-26 22:28 ` Benjamin Herrenschmidt 2018-03-26 22:27 ` Jason Gunthorpe 2018-03-26 22:27 ` Jason Gunthorpe 2018-03-26 22:36 ` Benjamin Herrenschmidt 2018-03-26 22:36 ` Benjamin Herrenschmidt 2018-03-26 22:42 ` Benjamin Herrenschmidt 2018-03-26 22:42 ` Benjamin Herrenschmidt 2018-03-26 22:50 ` Jason Gunthorpe 2018-03-26 22:50 ` Jason Gunthorpe 2018-03-26 23:59 ` Benjamin Herrenschmidt 2018-03-26 23:59 ` Benjamin Herrenschmidt 2018-03-27 1:39 ` Jason Gunthorpe 2018-03-27 1:39 ` Jason Gunthorpe 2018-03-27 7:56 ` Arnd Bergmann 2018-03-27 7:56 ` Arnd Bergmann 2018-03-27 8:56 ` Benjamin Herrenschmidt 2018-03-27 8:56 ` Benjamin Herrenschmidt 2018-03-27 9:44 ` Arnd Bergmann 2018-03-27 9:44 ` Arnd Bergmann 2018-03-27 10:00 ` Will Deacon 2018-03-27 10:00 ` Will Deacon 2018-03-27 11:23 ` Benjamin Herrenschmidt 2018-03-27 11:23 ` Benjamin Herrenschmidt 2018-03-27 12:22 ` okaya 2018-03-27 12:22 ` okaya 2018-03-27 14:12 ` Jason Gunthorpe 2018-03-27 14:12 ` Jason Gunthorpe 2018-03-27 21:27 ` Benjamin Herrenschmidt 2018-03-27 21:27 ` Benjamin Herrenschmidt 2018-03-27 9:57 ` Will Deacon 2018-03-27 9:57 ` Will Deacon 2018-03-27 10:05 ` Arnd Bergmann 2018-03-27 10:05 ` Arnd Bergmann 2018-03-27 10:09 ` Will Deacon 2018-03-27 10:09 ` Will Deacon 2018-03-27 10:53 ` Arnd Bergmann 2018-03-27 10:53 ` Arnd Bergmann 2018-03-27 11:02 ` Will Deacon 2018-03-27 11:02 ` Will Deacon 2018-03-27 11:05 ` Arnd Bergmann 2018-03-27 11:05 ` Arnd Bergmann 2018-03-27 11:25 ` Benjamin Herrenschmidt 2018-03-27 11:25 ` Benjamin Herrenschmidt 2018-03-27 13:20 ` David Laight 2018-03-27 13:20 ` David Laight 2018-03-27 13:46 ` Sinan Kaya 2018-03-27 13:46 ` Sinan Kaya 2018-03-27 14:36 ` Will Deacon 2018-03-27 14:36 ` Will Deacon 2018-03-27 21:29 ` Benjamin Herrenschmidt 2018-03-27 21:29 ` Benjamin Herrenschmidt 2018-03-28 8:53 ` Will Deacon 2018-03-28 8:53 ` Will Deacon 2018-03-28 9:00 ` David Laight 2018-03-28 9:00 ` David Laight 2018-03-28 9:09 ` Will Deacon 2018-03-28 9:09 ` Will Deacon 2018-03-28 9:56 ` Benjamin Herrenschmidt 2018-03-28 9:56 ` Benjamin Herrenschmidt 2018-03-28 9:50 ` Benjamin Herrenschmidt 2018-03-28 9:50 ` Benjamin Herrenschmidt 2018-03-28 9:55 ` Arnd Bergmann 2018-03-28 9:55 ` Arnd Bergmann 2018-03-28 10:01 ` Benjamin Herrenschmidt 2018-03-28 10:01 ` Benjamin Herrenschmidt 2018-03-28 10:13 ` Will Deacon 2018-03-28 10:13 ` Will Deacon 2018-03-28 16:57 ` Jason Gunthorpe 2018-03-28 16:57 ` Jason Gunthorpe 2018-03-29 9:19 ` Will Deacon 2018-03-29 9:19 ` Will Deacon 2018-03-29 14:45 ` Jason Gunthorpe 2018-03-29 14:45 ` Jason Gunthorpe 2018-03-29 14:58 ` David Laight 2018-03-29 14:58 ` David Laight 2018-03-29 16:40 ` Jason Gunthorpe 2018-03-29 16:40 ` Jason Gunthorpe 2018-03-27 21:24 ` Benjamin Herrenschmidt 2018-03-27 21:24 ` Benjamin Herrenschmidt 2018-03-27 11:21 ` Benjamin Herrenschmidt 2018-03-27 11:21 ` Benjamin Herrenschmidt 2018-03-27 9:42 ` Will Deacon 2018-03-27 9:42 ` Will Deacon 2018-03-27 11:20 ` Benjamin Herrenschmidt 2018-03-27 11:20 ` Benjamin Herrenschmidt 2018-03-27 11:24 ` Will Deacon 2018-03-27 11:24 ` Will Deacon 2018-03-27 14:24 ` Jason Gunthorpe 2018-03-27 14:24 ` Jason Gunthorpe 2018-03-27 14:16 ` Jason Gunthorpe 2018-03-27 14:16 ` Jason Gunthorpe 2018-03-26 22:00 ` Benjamin Herrenschmidt 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 19:54 ` Arnd Bergmann 2018-03-27 20:46 ` 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:53 ` Linus Torvalds 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 11:30 ` David Laight 2018-03-28 15:12 ` Benjamin Herrenschmidt 2018-03-28 16:16 ` David Laight 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 2018-03-26 21:26 ` Benjamin Herrenschmidt 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=1521726722.16434.312.camel@kernel.crashing.org \ --to=benh@kernel.crashing.org \ --cc=linux-rdma@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=okaya@codeaurora.org \ --cc=oohall@gmail.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.