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@xxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
