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