linux-kernel - Re: [linus:master] [mm] cacded5e42: aim9.brk_test.ops_per

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]

Message-ID: <ac1e101c-f3ed-4e9a-9ef4-37788fce4680@lucifer.local>
Date: Thu, 17 Oct 2024 09:54:13 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Oliver Sang <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mark Brown <broonie@...nel.org>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Bert Karwatzki <spasswolf@....de>,
        Jeff Xu <jeffxu@...omium.org>, Jiri Olsa <olsajiri@...il.com>,
        Kees Cook <kees@...nel.org>, Lorenzo Stoakes <lstoakes@...il.com>,
        Matthew Wilcox <willy@...radead.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Paul Moore <paul@...l-moore.com>,
        Sidhartha Kumar <sidhartha.kumar@...cle.com>,
        Suren Baghdasaryan <surenb@...gle.com>, linux-mm@...ck.org,
        ying.huang@...el.com, feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linus:master] [mm]  cacded5e42:  aim9.brk_test.ops_per_sec
 -5.0% regression

On Thu, Oct 17, 2024 at 10:58:38AM +0800, Oliver Sang wrote:
> hi, Lorenzo,
>
> On Tue, Oct 15, 2024 at 08:56:28PM +0100, Lorenzo Stoakes wrote:
> > On Fri, Oct 11, 2024 at 08:26:37AM +0100, Lorenzo Stoakes wrote:
> > [snip]
> >
> > > Thanks for testing this suffices to rule this one out... I will try to get a
> > > functional and reliable performance environment locally so I can properly
> > > address this and then we can try something else.
> > >
> > > Thanks!
> > > Lorenzo
> > >
> >
> > OK Oliver, could you try the below patch? I have got aim9.brk up and
> > running locally and for me this seems to address the issue.
> >
> > This is against Andrew's tree [0] in the mm-unstable branch. It should
> > hopefully apply cleanly to -next also.
>
> I found the patch still be able to applied to cacded5e42 cleanly, so below data
> still based on this applyment.
>
> $ git log --oneline 9cecc5dc893886
> 9cecc5dc893886 mm: add expand-only VMA merge mode and optimise do_brk_flags()
> cacded5e42b960 mm: avoid using vma_merge() for new VMAs
> fc21959f74bc11 mm: abstract vma_expand() to use vma_merge_struct
> ...
>
> again, if some patches in mm-unstable or -next have some impacts, please let me
> know then I can re-apply the patch and do the tests again. thanks
>
>
> by this patch, we do see performance recovery but not fully.
>
> e.g. for
> model: Granite Rapids
> nr_node: 1
> nr_cpu: 240
> memory: 192G
>
> we got better score from the patch than cacded5e42b960, but still 2.0%
> regression than fc21959f74bc11 (the parent of cacded5e42b960)

Thanks for this. As far as I'm concerned this puts us into noise territory,
so we'll go with this as the solution!

A side-note, the brk2 test from the will-it-scale suite, written explicitly
to be more real-world representative, sees an actual performance
_improvement_ here (though small).

So overall I'm comfortable with this, we can revisit if anybody raises any
objection! The benefit in de-duplicating code is very significant.

Thanks for all your help, hugely appreciated!

Cheers, Lorenzo

[snip]