LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jean-Marc Valin <jmvalin@mozilla.com>
To: "Christian König" <christian.koenig@amd.com>,
airlied@linux.ie, alexander.deucher@amd.com,
Felix.Kuehling@amd.com, labbott@redhat.com,
akpm@linux-foundation.org, michel.daenzer@amd.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: AMD graphics performance regression in 4.15 and later
Date: Fri, 6 Apr 2018 11:30:02 -0400 [thread overview]
Message-ID: <a96df0b8-fc22-4438-646d-2f0096dfcc84@mozilla.com> (raw)
In-Reply-To: <9ca940f1-7f21-c420-de45-13d72e783ab6@amd.com>
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time? Right
now the recent kernels are making Firefox pretty much unusable for me.
I've been able to revert the patch from 4.15 but it's not really a
long-term solution.
You mention that the purpose of the patch is to improve performance, but
I haven't actually noticed anything running faster on my system. Is
there any particular test where I'm supposed to see an improvement
compared to 4.14?
I'm not sure what you mean by "We mitigated the problem by avoiding the
slow coherent DMA code path on almost all platforms on newer kernels". I
tested up to 4.16 and the performance regression is just as bad as it is
for 4.15.
Unlike the older hardware reported on kernel bug 198511, the hardware I
have is quite recent (RX 560) and still being sold. I've also confirmed
that neither nvidia (on the same machine) nor intel GPUs (on a less
powerful machine) are affected, so it seems like there's a way to avoid
that slow performance. I'm not saying that what Firefox is doing is
ideal (I don't know what it does and why), but it still seems like
something that should still be avoided in the kernel.
Cheers,
Jean-Marc
On 04/06/2018 04:03 AM, Christian König wrote:
> Hi Jean,
>
> yeah, that is a known problem. Using huge pages improves the performance
> because of better TLB usage, but for the cost of higher allocation
> overhead.
>
> What we found is that firefox is doing something rather strange by
> allocating large textures and then just trowing them away again
> immediately.
>
> We mitigated the problem by avoiding the slow coherent DMA code path on
> almost all platforms on newer kernels, but essentially somebody needs to
> figure out why firefox and/or the user space stack is doing this
> constant allocation/freeing of memory.
>
> There is also a bug tracker on bugs.kernel.org about this, but I can't
> find it any more of hand.
>
> Regards,
> Christian.
>
> Am 06.04.2018 um 02:30 schrieb Jean-Marc Valin:
>> Hi,
>>
>> I noticed a serious graphics performance regression between 4.14 and
>> 4.15. It is most noticeable with Firefox (tried FF57 through FF60) and
>> causes scrolling to be really choppy/sluggish. I've confirmed that the
>> problem is also there on 4.16, while 4.13 works fine.
>>
>> After a bisection, I've narrowed the regression down to this commit:
>>
>> commit 648bc3574716400acc06f99915815f80d9563783
>> Author: Christian König <christian.koenig@amd.com>
>> Date: Thu Jul 6 09:59:43 2017 +0200
>>
>> drm/ttm: add transparent huge page support for DMA allocations v2
>>
>>
>> Some details about my system:
>> Distro: Fedora 27 (up-to-date)
>> Video: MSI Radeon RX 560 AERO
>> CPU: Dual-socket Xeon E5-2640 v4 (20 cores total)
>> RAM: 128 GB ECC
>>
>>
>> As a comparison, when running Firefox with 4.15 on a Lenovo W540 laptop
>> (with Intel graphics only) the responsiveness is much better then what
>> I'm getting on the Xeon machine above with the Radeon card, so this
>> really seems to be an AMD-only issue.
>>
>> Any way to fix the issue?
>>
>> Thanks,
>>
>> Jean-Marc
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
next prev parent reply other threads:[~2018-04-06 15:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-06 0:30 AMD graphics performance regression in 4.15 and later Jean-Marc Valin
2018-04-06 8:03 ` Christian König
2018-04-06 8:10 ` Christian König
2018-04-06 15:30 ` Jean-Marc Valin [this message]
2018-04-09 11:48 ` Christian König
2018-04-06 16:42 ` Jean-Marc Valin
2018-04-06 17:20 ` Christian König
2018-04-06 22:00 ` Jean-Marc Valin
2018-04-09 9:42 ` Christian König
2018-04-09 15:17 ` Jean-Marc Valin
2018-04-10 6:48 ` Christian König
2018-04-11 4:00 ` Gabriel C
2018-04-11 5:02 ` Gabriel C
2018-06-06 11:28 ` Gabriel C
2018-06-06 11:33 ` Christian König
2018-06-06 12:08 ` Gabriel C
2018-06-06 12:19 ` Christian König
2018-04-11 9:37 ` Christian König
2018-04-11 14:26 ` Gabriel C
2018-04-11 17:21 ` Gabriel C
2018-04-11 18:35 ` Jean-Marc Valin
2018-04-11 22:20 ` Gabriel C
2018-04-12 1:47 ` Gabriel C
2018-04-20 14:47 ` Michel Dänzer
2018-04-20 19:40 ` Felix Kuehling
2018-04-23 10:23 ` Michel Dänzer
2018-07-13 2:23 ` Jean-Marc Valin
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=a96df0b8-fc22-4438-646d-2f0096dfcc84@mozilla.com \
--to=jmvalin@mozilla.com \
--cc=Felix.Kuehling@amd.com \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michel.daenzer@amd.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).