lkml.org 
[lkml]   [2018]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: AMD graphics performance regression in 4.15 and later
    From
    Date
    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@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
    >
    \
     
     \ /
      Last update: 2018-07-15 22:06    [W:4.105 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site