linux-kernel - Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 Jun 2018 14:32:46 +0200
From:   Gabriel C <nix.or.die@...il.com>
To:     Christian König <christian.koenig@....com>
Cc:     Michel Dänzer <michel@...nzer.net>,
        Jean-Marc Valin <jmvalin@...illa.com>,
        Dave Airlie <airlied@...ux.ie>,
        Felix Kuehling <Felix.Kuehling@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        dri-devel@...ts.freedesktop.org, alexander.deucher@....com,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Joerg Roedel <jroedel@...e.de>, Christoph Hellwig <hch@....de>
Subject: Re: Kernel and ADM hardware roulette ( was AMD graphics performance
 regression in 4.15 and later )

2018-06-07 9:07 GMT+02:00 Christian König <christian.koenig@....com>:
> Am 06.06.2018 um 17:44 schrieb Gabriel C:
>>
>> 2018-06-06 17:03 GMT+02:00 Michel Dänzer <michel@...nzer.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@....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@....com>
>>>>      Reviewed-by: Monk Liu <monk.liu@....com>
>>>>      Reviewed-by: Christian König <christian.koenig@....com>
>>>>      Signed-off-by: Alex Deucher <alexander.deucher@....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@....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@....com>
>     Reviewed-by: Monk Liu <monk.liu@....com>
>     Reviewed-by: Christian König <christian.koenig@....com>
>     Signed-off-by: Alex Deucher <alexander.deucher@....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@....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@....com>
   Tested-by: Joerg Roedel <jroedel@...e.de>
   Signed-off-by: Christoph Hellwig <hch@....de>
   Reviewed-by: Thomas Gleixner <tglx@...utronix.de>
   Acked-by: Joerg Roedel <jroedel@...e.de>
   Cc: David Woodhouse <dwmw2@...radead.org>
   Cc: Joerg Roedel <joro@...tes.org>
   Cc: Jon Mason <jdmason@...zu.us>
   Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
   Cc: Linus Torvalds <torvalds@...ux-foundation.org>
   Cc: Muli Ben-Yehuda <mulix@...ix.org>
   Cc: Peter Zijlstra <peterz@...radead.org>
   Cc: iommu@...ts.linux-foundation.org
   Link: http://lkml.kernel.org/r/20180319103826.12853-8-hch@lst.de
   Signed-off-by: Ingo Molnar <mingo@...nel.org>


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

BR