Messages in this thread | | | Subject | Re: AMD graphics performance regression in 4.15 and later | From | Christian König <> | Date | Mon, 9 Apr 2018 13:48:27 +0200 |
| |
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
| |