From: Marc Zyngier <marc.zyngier@arm.com>
To: Andrzej Hajda <a.hajda@samsung.com>,
Archit Taneja <architt@codeaurora.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/bridge: analogix_dp: Use relaxed MMIO accessors
Date: Tue, 19 Dec 2017 11:18:07 +0000 [thread overview]
Message-ID: <cb97ac46-33f3-d06e-53de-00945549e19b@arm.com> (raw)
In-Reply-To: <1a70f78c-a94c-4fcf-e89d-da90973cbc79@samsung.com>
On 19/12/17 08:53, Andrzej Hajda wrote:
> On 18.12.2017 12:39, Marc Zyngier wrote:
>> The analogix DP bridge is entierely driven via MMIO accesses, and
>> does not do any DMA that requires coherency with the CPU. Yet, the
>> driver uses the non-relaxed accessors, forcing strong barriers to
>> be emitted on architectures with a relaxed memory ordering.
>>
>> This is of course completely unnecessary, and only serves as a way
>> to pointlessly reduce the performance of unsuspecting platforms.
>>
>> Switch the driver to the _relaxed accessors, making my kevin platform
>> a slightly better machine.
>
> Do you have any stats to justify this change?
I do (sort of): "hackbench 100 process 1000" is a almost a second faster
with that change (that's about 2% on something that is essentially a
scheduler benchmark) on my rk3399 system. Yes, this is a silly
benchmark, but that's one you can easily run on about anything.
> The common practice is/was to use writel/readl accessors to access MMIO,
> even if it is suboptimal in many cases. Has something changed in these
> practices?
Having it as a default is acceptable, unless you actually understand the
implications of the relaxed accessors and find that they have an impact
on the system.
To give you an idea of the magnitude of the impact on an arm64 system,
each barrier does:
- force the completion of any memory access in the whole system
- force the completion of any in-flight TLB invalidation and cache
maintenance in the whole system
When I say "in the whole system", it means CPUs, GPU, and any other
piece of HW connected on the system. This is effectively a "wait until
everything that was in-flight is done".
This is a widespread issue that takes time to address, unfortunately.
Now, I've definitely applied brute force to this driver, not really
knowing all the intricacies of the device. I haven't seen anything
bizarre there (it is mostly a bunch of RMWs), but I'd appreciate someone
who knows this IP to review it.
> To be clear, I am not against this change. I am just curious.
There is a really good article that explains all (and quite a bit more)
a kernel developer needs to know about MMIO and relaxed accessors here:
https://lwn.net/Articles/698014/
Hope this helps,
M.
--
Jazz is not dead. It just smells funny...
prev parent reply other threads:[~2017-12-19 11:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 11:39 Marc Zyngier
[not found] ` <CGME20171219085343eucas1p18d361316271ce95bd3778aad118993bb@eucas1p1.samsung.com>
2017-12-19 8:53 ` Andrzej Hajda
2017-12-19 11:18 ` Marc Zyngier [this message]
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=cb97ac46-33f3-d06e-53de-00945549e19b@arm.com \
--to=marc.zyngier@arm.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=architt@codeaurora.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.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
all inboxes | Powered by JetHome®