From: Sinan Kaya <okaya@codeaurora.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
Matt Turner <mattst88@gmail.com>,
linux-alpha@vger.kernel.org, okaya@kernel.org,
Will Deacon <will.deacon@arm.com>,
linux-arch <linux-arch@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130
Date: Wed, 22 Aug 2018 16:06:09 -0400 [thread overview]
Message-ID: <89256c73-d8e5-3e8f-e796-9b2f1d2f9522@codeaurora.org> (raw)
In-Reply-To: <alpine.LRH.2.02.1808221545230.2965@file01.intranet.prod.int.rdu2.redhat.com>
On 8/22/2018 3:56 PM, Mikulas Patocka wrote:
>
>
> On Wed, 22 Aug 2018, Sinan Kaya wrote:
>
>> On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
>>> If ARM guarantees that the accesses to a given device are not reordered -
>>> then the barriers in readl and writel are superfluous.
>>
>> It is not. ARM only guarantees ordering of read/write transactions targeting
>> a device not memory.
>>
>> example:
>>
>> write memory
>> raw write to device
>>
>> or
>>
>> raw read from device
>> read memory
>>
>> these can bypass each other on ARM unless a barrier is placed in the right
>> place either via readl()/writel() or explicitly.
>
> Yes - but - why does Linux insert the barriers into readl() and writel()
> instead of inserting them between accesses to registers and memory?
>
> A lot of drivers have long sequences of accesses to memory-mapped
> registers with no interleaving accesses to coherent memory and these
> implicit barriers slow them down with no gain at all.
It is an abstraction issue. Majority of drivers are developed against x86
and the developers have no idea about the weakly ordered architecture
implications.
Now, Will Deacon added new primitives to address your concern. There are
new APIs as readl_relaxed() and writel_relaxed() as opposed to readl()
and writel().
Relaxed version still guarantee of register accesses with respect to each
other but no guaranteed with respect to memory. Relaxed versions could
be used in performance critical path.
>
> Mikulas
>
next prev parent reply other threads:[~2018-08-22 23:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LRH.2.02.1808161556450.13597@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <CAK8P3a09jqhxYah6SZUjbku3NGiPX2PyhA+jJNG7VzJUnwUZKQ@mail.gmail.com>
[not found] ` <alpine.LFD.2.21.1808172254110.26277@eddie.linux-mips.org>
[not found] ` <CAK8P3a3kq35zny70Mnzmk9Tzfm2U9DLPNMyBrursPtOHpOyJSw@mail.gmail.com>
[not found] ` <28597e7477418ac7cb646e2edb5e6da2@codeaurora.org>
[not found] ` <alpine.LRH.2.02.1808201010200.15146@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <CAK8P3a3ribyvLwXaB=J4dcTwD9aYc64hfw+ORTFtyvOHuS-U0g@mail.gmail.com>
[not found] ` <alpine.LRH.2.02.1808201740170.2948@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <CAK8P3a1E2V-zFN5PpJ868L=6CgTykkyjtF6-aTsCCh6QqryUig@mail.gmail.com>
[not found] ` <alpine.LRH.2.02.1808210814250.24287@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <CAK8P3a3vJK1caKpDqkEhMG=8n8N3U6ckqe=0f2fjUJwk-9K0XA@mail.gmail.com>
[not found] ` <alpine.LRH.2.02.1808220743270.12730@file01.intranet.prod.int.rdu2.redhat.com>
[not found] ` <21c0bd37-0ae7-db8f-76b8-6552c30faa4f@codeaurora.org>
[not found] ` <alpine.LFD.2.21.1808221609000.26277@eddie.linux-mips.org>
2018-08-22 15:50 ` Alpha Avanti broken by 9ce8654323d69273b4977f76f11c9e2d345ab130 Mikulas Patocka
2018-08-22 16:06 ` Arnd Bergmann
2018-08-22 17:20 ` Maciej W. Rozycki
2018-08-22 17:47 ` Mikulas Patocka
2018-08-22 19:38 ` Sinan Kaya
2018-08-22 19:56 ` Mikulas Patocka
2018-08-22 20:03 ` Will Deacon
2018-08-22 20:06 ` Sinan Kaya [this message]
2018-08-22 20:12 ` Will Deacon
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=89256c73-d8e5-3e8f-e796-9b2f1d2f9522@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=arnd@arndb.de \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mattst88@gmail.com \
--cc=mpatocka@redhat.com \
--cc=okaya@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.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: 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).