AMD graphics performance regression in 4.15 and later

[Christian König]

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 at 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 at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel