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@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
