Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: AMD graphics performance regression in 4.15 and later
To:     =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>,
        airlied@linux.ie, alexander.deucher@amd.com,
        Felix.Kuehling@amd.com, labbott@redhat.com,
        akpm@linux-foundation.org, michel.daenzer@amd.com,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
References: <c743b220-0395-eef3-4405-a21cdbe8eee1@mozilla.com>
 <9ca940f1-7f21-c420-de45-13d72e783ab6@amd.com>
 <a96df0b8-fc22-4438-646d-2f0096dfcc84@mozilla.com>
 <6cebabff-908f-5ebe-4252-760773c4cd6f@amd.com>
From:   Jean-Marc Valin <jmvalin@mozilla.com>
Message-ID: <b7d904c9-7f1d-1906-b2ce-4420847445f1@mozilla.com>
Date:   Thu, 12 Jul 2018 22:23:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <6cebabff-908f-5ebe-4252-760773c4cd6f@amd.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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
>