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: Thu, 12 Jul 2018 22:23:30 -0400 [thread overview]
Message-ID: <b7d904c9-7f1d-1906-b2ce-4420847445f1@mozilla.com> (raw)
In-Reply-To: <6cebabff-908f-5ebe-4252-760773c4cd6f@amd.com>
Hi Christian,
Sorry for the delayed response, but I just thought I'd confirm that
kernel 4.17 (4.17.3-100.fc27.x86_64 to be more precise) seems to be
working fine for me, with no performance issue.
Cheers,
Jean-Marc
On 04/09/2018 07:48 AM, Christian König wrote:
> Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
>> Hi Christian,
>>
>> Is there a way to turn off these huge pages at boot-time/run-time?
>
> Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
>
> Alternatively you can avoid enabling CONFIG_SWIOTLB which will avoid the
> slow DMA path as well.
>
>> 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?
>
> Mostly crypto mining, maybe some games as well.
>
>> 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.
>
> Indeed 4.16 still doesn't have that. You could use the
> amd-staging-drm-next branch or wait for 4.17.
>
>> Unlike the older hardware reported on kernel bug 198511, the hardware I
>> have is quite recent (RX 560) and still being sold.
>
> That isn't related to the GFX hardware, but to your CPU/motherboard and
> whatever else you have in the system.
>
> Some part of your system needs SWIOTLB and that makes allocating memory
> much slower.
>
>> 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.
>
> Intel doesn't use TTM because they don't have dedicated VRAM, but the
> open source nvidia driver should be affected as well.
>
>> 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.
>
> We already mitigated that problem and I don't see any solution which
> will arrive faster than 4.17.
>
> The only quick workaround I can see is to avoid firefox, chrome for
> example is reported to work perfectly fine.
>
> Christian.
>
>>
>> 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
>
prev parent reply other threads:[~2018-07-13 2:23 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
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 [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=b7d904c9-7f1d-1906-b2ce-4420847445f1@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).