linux-kernel - Re: [drm/mgag200] 913ec479bb: vm-scalability.throughput 26.2% improvement

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] [day] [month] [year] [list]

Date:   Mon, 31 Aug 2020 14:11:26 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Thomas Zimmermann <tzimmermann@...e.de>
Cc:     Mike Kravetz <mike.kravetz@...cle.com>,
        kernel test robot <rong.a.chen@...el.com>,
        John Donnelly <John.p.donnelly@...cle.com>,
        Emil Velikov <emil.velikov@...labora.com>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
        lkp@...el.com, ying.huang@...el.com, zhengjun.xing@...el.com
Subject: Re: [drm/mgag200] 913ec479bb: vm-scalability.throughput 26.2%
 improvement

On Sat, Aug 29, 2020 at 08:06:04PM +0200, Thomas Zimmermann wrote:
> > Hello Thomas,
> > 
> > Did drm changes really impact anon-cow-seq-hugetlb performance?
> >
> > My change c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing
> > synchronization") caused a -33.4% regression of anon-cow-seq-hugetlb.  A
> > recent change 34ae204f185 (hugetlbfs: remove call to huge_pte_alloc without
> > i_mmap_rwsem) was tested by Zhengjun Xing and improved performance by 20
> > something percent.  That seems in line with this report/improvement.
> 
> Some of DRM's memory management might be affected by hugetable changes.
> While I cannot really point to a specific location, it's not impossible
> that there's a connection.
> 
> > 
> > Perhaps the tooling is not always accurate in determining the commit which
> > causes the performance changes?
> > Perhaps I am misreading information in the reports?
> > 
> 
> From what I remember, some of these tests print to the console, which
> has always been slow, and has generally been a bad idea for performance
> tests. I guess these tests are not very accurate.

Yes, I also think that's the reason for this improvement. The test box is
using mgag200 driver, while the vm-scalability test case itself will print
many messages to the gfx console. If commit 913ec479bb "drm/mgag200: Replace
VRAM helpers with SHMEM helpers" improves the console handling, then it
will impact the final score of the test case.

Last time we met similar case that a console write slowdown triggers a
regression is discussed here:  
https://lore.kernel.org/lkml/20190729095155.GP22106@shao2-debian/

Thanks,
Feng

> Best regards
> Thomas