Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )

[Gabriel C]

2018-06-07 9:07 GMT+02:00 Christian König <christian.koenig at amd.com>:
> Am 06.06.2018 um 17:44 schrieb Gabriel C:
>>
>> 2018-06-06 17:03 GMT+02:00 Michel Dänzer <michel at daenzer.net>:
>>>
>>> On 2018-06-06 04:44 PM, Christian König wrote:
>>>>
>>>> Am 06.06.2018 um 16:12 schrieb Michel Dänzer:
>>>> [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 at 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 at amd.com>
>>>>      Reviewed-by: Monk Liu <monk.liu at amd.com>
>>>>      Reviewed-by: Christian König <christian.koenig at amd.com>
>>>>      Signed-off-by: Alex Deucher <alexander.deucher at 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 at 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 slower
>     than ttm pool allocation.
>     So add condition to use it.
>     v2: move a bit later
>
>     Signed-off-by: Chunming Zhou <david1.zhou at amd.com>
>     Reviewed-by: Monk Liu <monk.liu at amd.com>
>     Reviewed-by: Christian König <christian.koenig at amd.com>
>     Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
>     Link:
> https://patchwork.freedesktop.org/patch/msgid/20180209024410.1469-3-david1.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 like
>> 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 at lst.de>
Date:   Mon Mar 19 11:38:19 2018 +0100

   iommu/amd_iommu: Use CONFIG_DMA_DIRECT_OPS=y and dma_direct_{alloc,free}()

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

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


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

BR