From: Akira Yokosawa <akiyks@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>, Parav Pandit <parav@nvidia.com>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
parri.andrea@gmail.com, Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
boqun.feng@gmail.com, Nicholas Piggin <npiggin@gmail.com>,
dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr,
"Paul E. McKenney" <paulmck@kernel.org>,
dlustig@nvidia.com, Joel Fernandes <joel@joelfernandes.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-kernel@vger.kernel.org,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-doc@vger.kernel.org, Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [PATCH v4] locking/memory-barriers.txt: Improve documentation for writel() example
Date: Tue, 18 Oct 2022 18:23:39 +0900 [thread overview]
Message-ID: <a9c64b36-9770-1198-7958-3d66b98737c1@gmail.com> (raw)
In-Reply-To: <b88e4bd2-5c2e-430a-99f9-18cd43463fd6@app.fastmail.com>
On Tue, 18 Oct 2022 09:49:34 +0200, Arnd Bergmann wrote:
> On Tue, Oct 18, 2022, at 9:40 AM, Akira Yokosawa wrote:
>> On Tue, 18 Oct 2022 08:44:09 +0200, Arnd Bergmann wrote:
>>>
>>> Anything weaker than a full "wmb()" probably makes the driver calling
>>> the writel() non-portable, so that is both vague and incorrect.
>>
>> Do you mean there is a writel() implementation somewhere in the kernel
>> which doesn't guarantee an implicit wmb() before MMIO write?
>
> There are lots of those, but that's not what I meant. E.g. on x86,
> writel() does not imply a full wmb() but still guarantees serialization
> between DMA and the register access.
>
>> Or do you mean my version is confusing because it can imply a weaker
>> write barrier is sufficient before writel_relaxed()?
>
> That's what I meant, yes. On a lot of architectures, it is sufficient
> to have something weaker than wmb() before writel_relaxed(), especially
> on anything that defines writel_relaxed() to be the same as writel(),
> any barrier would technically work. On arm32, using __iowmb() would be
> sufficient, and this can be less than a full wmb() but again it's
> obviously not portable. These details should not be needed in the
> documentation.
Thanks for the clarification.
I think I was confused by the current wording.
I might be wrong, but I guess Parav's motivation of this change was
to prevent this kind of confusion from the first place.
Parav, may I suggest a reworked changelog? :
The cited commit describes that when using writel(), explcit wmb()
is not needed. However, wmb() can be an expensive barrier depending
on platforms. Arch-specific writel() can use a platform-specific
weaker barrier needed for the guarantee mentioned in section "KERNEL
I/O BARRIER EFFECTS".
Current wording of:
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 MMIO region.
is confusing because it can be interpreted that writel() always has
a barrier equivalent to the heavy-weight wmb(), which is not the case.
Hence stop mentioning wmb() and just call "a prior barrier" in the
notice.
commit 5846581e3563 ("locking/memory-barriers.txt: Fix broken DMA vs. MMIO ordering example")
Am I still missing something?
Thanks, Akira
>
> Arnd
next prev parent reply other threads:[~2022-10-18 9:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-10 10:13 [PATCH v4] locking/memory-barriers.txt: Improve documentation for writel() example Parav Pandit
2022-10-17 20:55 ` Arnd Bergmann
2022-10-18 1:37 ` Akira Yokosawa
2022-10-18 6:44 ` Arnd Bergmann
2022-10-18 7:40 ` Akira Yokosawa
2022-10-18 7:49 ` Arnd Bergmann
2022-10-18 9:23 ` Akira Yokosawa [this message]
2022-10-18 10:05 ` Will Deacon
2022-10-18 17:49 ` Paul E. McKenney
2022-10-18 20:33 ` Parav Pandit
2022-10-27 18:15 ` Paul E. McKenney
2022-10-27 18:24 ` Parav Pandit
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=a9c64b36-9770-1198-7958-3d66b98737c1@gmail.com \
--to=akiyks@gmail.com \
--cc=arnd@arndb.de \
--cc=bagasdotme@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parav@nvidia.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will@kernel.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