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
