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;
MIME-Version: 1.0
In-Reply-To: <267c42ce-91e2-4843-3815-904ac74b2f44@amd.com>
References: <CAEJqkgiNVDzboDK1vsn9rYP0G=Q_mGDrkx1VVB8TUkm35Rs9fA@mail.gmail.com>
 <516cddbe-73c2-01f3-a552-0d9fd75ce63a@amd.com> <8f7d00f9-992f-cc07-6bd0-b1b47c5d2ccf@amd.com>
 <ae904954-18f7-180a-ce69-7e7618bd398f@daenzer.net> <CAEJqkgjErpxG44CZXn2BzvPES7Ptf24ae6748dAcYdg2n5HuZw@mail.gmail.com>
 <267c42ce-91e2-4843-3815-904ac74b2f44@amd.com>
From:   Gabriel C <nix.or.die@gmail.com>
Date:   Thu, 7 Jun 2018 14:32:46 +0200
Message-ID: <CAEJqkggsjnod79HFvYQHRFEsFaN-bb27P8Xf79_9DmxhLKs_Og@mail.gmail.com>
Subject: Re: Kernel and ADM hardware roulette ( was AMD graphics performance
 regression in 4.15 and later )
To:     =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>
Cc:     =?UTF-8?Q?Michel_D=C3=A4nzer?= <michel@daenzer.net>,
        Jean-Marc Valin <jmvalin@mozilla.com>,
        Dave Airlie <airlied@linux.ie>,
        Felix Kuehling <Felix.Kuehling@amd.com>,
        LKML <linux-kernel@vger.kernel.org>,
        dri-devel@lists.freedesktop.org, alexander.deucher@amd.com,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Joerg Roedel <jroedel@suse.de>, Christoph Hellwig <hch@lst.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

2018-06-07 9:07 GMT+02:00 Christian K=C3=B6nig <christian.koenig@amd.com>:
> Am 06.06.2018 um 17:44 schrieb Gabriel C:
>>
>> 2018-06-06 17:03 GMT+02:00 Michel D=C3=A4nzer <michel@daenzer.net>:
>>>
>>> On 2018-06-06 04:44 PM, Christian K=C3=B6nig wrote:
>>>>
>>>> Am 06.06.2018 um 16:12 schrieb Michel D=C3=A4nzer:
>>>> [SNIP]
>>>> At least in theory it should work when we use the coherent DMA
>>>> allocator.
>>>>
>>>> When that really worked before, so the most likely commit which broke
>>>> this is:
>>>>
>>>> commit fd5fd480dd8fe4910546e7b080b3ae345e57fe9f
>>>> Author: Chunming Zhou <david1.zhou@amd.com>
>>>> Date:   Fri Feb 9 10:44:09 2018 +0800
>>>>
>>>>      drm/amdgpu: only enable swiotlb alloc when need v2
>>>>
>>>>      get the max io mapping address of system memory to see if it is
>>>> over
>>>>      our card accessing range.
>>>>      v2: move checking later
>>>>
>>>>      Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
>>>>      Reviewed-by: Monk Liu <monk.liu@amd.com>
>>>>      Reviewed-by: Christian K=C3=B6nig <christian.koenig@amd.com>
>>>>      Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>>>>
>>>> Currently looking into how we could somehow improve this detection.
>>>
>>> I guess this could fit for Gabriel, but e.g.
>>> https://bugs.freedesktop.org/104437 says amdgpu was already broken with
>>> SME in 4.15, if not 4.14 (I suspect there was simply no SME support
>>> earlier).
>
>
> And what I totally missed is that Gabriel is using radeon and not amdgpu.
>
> So Gabriel you need to revert this one for testing:
> commit 1bc3d3cce8c3b44c2b5ac6cee98c830bb40e6b0f
> Author: Chunming Zhou <david1.zhou@amd.com>
> Date:   Fri Feb 9 10:44:10 2018 +0800
>
>     drm/radeon: only enable swiotlb path when need v2
>
>     swiotlb expands our card accessing range, but its path always is slow=
er
>     than ttm pool allocation.
>     So add condition to use it.
>     v2: move a bit later
>
>     Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
>     Reviewed-by: Monk Liu <monk.liu@amd.com>
>     Reviewed-by: Christian K=C3=B6nig <christian.koenig@amd.com>
>     Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>     Link:
> https://patchwork.freedesktop.org/patch/msgid/20180209024410.1469-3-david=
1.zhou@amd.com
>
>> I got strange performance issue with 4.15 and 4.16 .. but SME was ON
>> on that setup ( even before it hit mainline ) and never broke the GPU li=
ke
>> this.
>
>
> Well that is very interesting, you are the first one who reports that SME=
 +
> GFX works in some way. So far we only got negative reports for that.
>
>> There is a 4.16.13 boot dmesg which has no such issue:
>>
>>
>> http://ftp.frugalware.org/pub/other/people/crazy/radeon/dmesg-radeon-SME=
-ON-kernel-4.16.txt
>>
>> With the setup as is booting 4.16.x works , while 4.17 trows the errors.
>
>
> Please do the bisect if the patch I've mentioned above doesn't help.

Ok done.. bisect points to:

b468620f2a1dfdcfddfd6fa54367b8bcc1b51248 is the first bad commit
commit b468620f2a1dfdcfddfd6fa54367b8bcc1b51248
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Mar 19 11:38:19 2018 +0100

   iommu/amd_iommu: Use CONFIG_DMA_DIRECT_OPS=3Dy and dma_direct_{alloc,fre=
e}()

   This cleans up the code a lot by removing duplicate logic.

   Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
   Tested-by: Joerg Roedel <jroedel@suse.de>
   Signed-off-by: Christoph Hellwig <hch@lst.de>
   Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
   Acked-by: Joerg Roedel <jroedel@suse.de>
   Cc: David Woodhouse <dwmw2@infradead.org>
   Cc: Joerg Roedel <joro@8bytes.org>
   Cc: Jon Mason <jdmason@kudzu.us>
   Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
   Cc: Linus Torvalds <torvalds@linux-foundation.org>
   Cc: Muli Ben-Yehuda <mulix@mulix.org>
   Cc: Peter Zijlstra <peterz@infradead.org>
   Cc: iommu@lists.linux-foundation.org
   Link: http://lkml.kernel.org/r/20180319103826.12853-8-hch@lst.de
   Signed-off-by: Ingo Molnar <mingo@kernel.org>


I'll try to revert this once I'm home.

BR