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:     Jean-Marc Valin <jmvalin@mozilla.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>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
Message-ID: <6cebabff-908f-5ebe-4252-760773c4cd6f@amd.com>
Date:   Mon, 9 Apr 2018 13:48:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <a96df0b8-fc22-4438-646d-2f0096dfcc84@mozilla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Received-SPF: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2018 15:48:41.3301 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b4ee9e9f-52af-45cb-5047-08d59bd5e08d
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1721
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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