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, christian.koenig@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>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
Message-ID: <9ca940f1-7f21-c420-de45-13d72e783ab6@amd.com>
Date:   Fri, 6 Apr 2018 10:03:41 +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: <c743b220-0395-eef3-4405-a21cdbe8eee1@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 08:03:52.1980 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: da184ee0-1501-4db7-2ba1-08d59b94f0cb
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1718
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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