linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).