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