From: Arnd Bergmann <arnd@arndb.de> To: Jason Gunthorpe <jgg@ziepe.ca> Cc: Sinan Kaya <okaya@codeaurora.org>, "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>, David Laight <David.Laight@aculab.com>, Oliver <oohall@gmail.com>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org> Subject: Re: RFC on writel and writel_relaxed Date: Mon, 26 Mar 2018 22:43:43 +0200 [thread overview] Message-ID: <CAK8P3a3fc43ZcW626hmsd3DVcLw7hGkdUMxp7s4Rn3mdkziwMQ@mail.gmail.com> (raw) In-Reply-To: <20180326202545.GB15554@ziepe.ca> On Mon, Mar 26, 2018 at 10:25 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote: > On Mon, Mar 26, 2018 at 09:44:15PM +0200, Arnd Bergmann wrote: >> On Mon, Mar 26, 2018 at 6:54 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote: >> > On Mon, Mar 26, 2018 at 11:08:45AM +0000, David Laight wrote: >> >> > > This is a super performance critical operation for most drivers and >> >> > > directly impacts network performance. >> >> >> >> Perhaps there ought to be writel_nobarrier() (etc) that never contain >> >> any barriers at all. >> >> This might mean that they are always just the memory operation, >> >> but it would make it more obvious what the driver was doing. >> > >> > I think that is what writel_relaxed is supposed to be. >> > >> > The only restriction it has is that the writes to a single device >> > using UC memory must be kept in program order.. >> >> Not sure about whether we have ever defined what happens to >> writel_relaxed() on WC memory though: On ARM, we disallow >> the compiler to combine writes, but the CPU still might. > > If the driver uses WC memory then I think it should not expect > anything in terms of how writes map to TLPs other than nothing > combines across mmiowb() and mmiowb() is fully globally ordered when > enclosed in a spinlock. > > The entire point of using WC memory is usually to get combining :) If > the driver doesn't want that then it should map UC.. Usually, WC memory is used with memcpy_toio() though, which by definition doesn't have any barriers between accesses, and is required to get the correct byte ordering on writes to memory buffers. >> It's also not entirely clear to me what we want writel() inside a >> spinlock to mean: should the spinlock guarantee that two writel() >> calls on different CPUs that are protected by spinlocks are >> serialized by those locks, or not? > > Yes for writel, I think that is already defined by the barriers > document Sorry, I meant writel_relaxed(), not writel() > The same document says that _relaxed() does not give that guarentee. > > The lwn articule on this went into some depth on the interaction with > spinlocks. > > As far as I can see, containment in a spinlock seems to be the only > different between writel and writel_relaxed.. I was always puzzled by this: The intention of _relaxed() on ARM (where it originates) was to skip the barrier that serializes DMA with MMIO, not to skip the serialization between MMIO and locks. I never fully understood the part about the locks, but from what I remember, ARM is still serialized without the barrier here, but dropping the barrier on powerpc writel_relaxed() would not serialize against locks or DMA. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de> To: Jason Gunthorpe <jgg@ziepe.ca> Cc: David Laight <David.Laight@aculab.com>, Sinan Kaya <okaya@codeaurora.org>, Oliver <oohall@gmail.com>, "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: Mon, 26 Mar 2018 22:43:43 +0200 [thread overview] Message-ID: <CAK8P3a3fc43ZcW626hmsd3DVcLw7hGkdUMxp7s4Rn3mdkziwMQ@mail.gmail.com> (raw) In-Reply-To: <20180326202545.GB15554@ziepe.ca> On Mon, Mar 26, 2018 at 10:25 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote: > On Mon, Mar 26, 2018 at 09:44:15PM +0200, Arnd Bergmann wrote: >> On Mon, Mar 26, 2018 at 6:54 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote: >> > On Mon, Mar 26, 2018 at 11:08:45AM +0000, David Laight wrote: >> >> > > This is a super performance critical operation for most drivers and >> >> > > directly impacts network performance. >> >> >> >> Perhaps there ought to be writel_nobarrier() (etc) that never contain >> >> any barriers at all. >> >> This might mean that they are always just the memory operation, >> >> but it would make it more obvious what the driver was doing. >> > >> > I think that is what writel_relaxed is supposed to be. >> > >> > The only restriction it has is that the writes to a single device >> > using UC memory must be kept in program order.. >> >> Not sure about whether we have ever defined what happens to >> writel_relaxed() on WC memory though: On ARM, we disallow >> the compiler to combine writes, but the CPU still might. > > If the driver uses WC memory then I think it should not expect > anything in terms of how writes map to TLPs other than nothing > combines across mmiowb() and mmiowb() is fully globally ordered when > enclosed in a spinlock. > > The entire point of using WC memory is usually to get combining :) If > the driver doesn't want that then it should map UC.. Usually, WC memory is used with memcpy_toio() though, which by definition doesn't have any barriers between accesses, and is required to get the correct byte ordering on writes to memory buffers. >> It's also not entirely clear to me what we want writel() inside a >> spinlock to mean: should the spinlock guarantee that two writel() >> calls on different CPUs that are protected by spinlocks are >> serialized by those locks, or not? > > Yes for writel, I think that is already defined by the barriers > document Sorry, I meant writel_relaxed(), not writel() > The same document says that _relaxed() does not give that guarentee. > > The lwn articule on this went into some depth on the interaction with > spinlocks. > > As far as I can see, containment in a spinlock seems to be the only > different between writel and writel_relaxed.. I was always puzzled by this: The intention of _relaxed() on ARM (where it originates) was to skip the barrier that serializes DMA with MMIO, not to skip the serialization between MMIO and locks. I never fully understood the part about the locks, but from what I remember, ARM is still serialized without the barrier here, but dropping the barrier on powerpc writel_relaxed() would not serialize against locks or DMA. Arnd
next prev parent reply other threads:[~2018-03-26 20:43 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 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 [this message] 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=CAK8P3a3fc43ZcW626hmsd3DVcLw7hGkdUMxp7s4Rn3mdkziwMQ@mail.gmail.com \ --to=arnd@arndb.de \ --cc=David.Laight@aculab.com \ --cc=jgg@ziepe.ca \ --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.