linux-kernel - Re: [percpu] ace7e70901: aim9.sync_disk_rw.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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 10 May 2021 17:34:38 -0700
From:   Roman Gushchin <guro@...com>
To:     Dennis Zhou <dennis@...nel.org>
CC:     Oliver Sang <oliver.sang@...el.com>,
        Pratik Sampat <psampat@...ux.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "lkp@...ts.01.org" <lkp@...ts.01.org>,
        "lkp@...el.com" <lkp@...el.com>,
        "ying.huang@...el.com" <ying.huang@...el.com>,
        "feng.tang@...el.com" <feng.tang@...el.com>,
        "zhengjun.xing@...el.com" <zhengjun.xing@...el.com>
Subject: Re: [percpu]  ace7e70901:  aim9.sync_disk_rw.ops_per_sec -2.3%
 regression

On Fri, May 07, 2021 at 07:08:03PM +0000, Dennis Zhou wrote:
> On Fri, May 07, 2021 at 10:52:22AM -0700, Roman Gushchin wrote:
> > On Fri, May 07, 2021 at 11:06:06AM +0800, Oliver Sang wrote:
> > > hi Roman,
> > >  
> > > On Thu, May 06, 2021 at 12:54:59AM +0000, Roman Gushchin wrote:
> > > > Ping
> > > 
> > > sorry for late.
> > > 
> > > the new patch makes the performance a little better but still has
> > > 1.9% regression comparing to
> > > f183324133 ("percpu: implement partial chunk depopulation")
> > 
> > Hi Oliver!
> > 
> > Thank you for testing it!
> > 
> > Btw, can you, please, confirm that the regression is coming specifically
> > from ace7e70901 ("percpu: use reclaim threshold instead of running for every page")?
> > I do see *some* regression in my setup, but the data is very noisy, so I'm not sure
> > I can confirm it.
> > 
> > Thanks!
> 
> Thanks Oliver and Roman. If this is the case, I'll drop the final patch
> and just merge up to f183324133 ("percpu: implement partial chunk
> depopulation") into for-next as this is v5.14 anyway.

I doubt it's a good idea. I reran the test with some debug added and it looks
like it doesn't  trigger any depopulation at all. Everything else looked sane
too.

Dropping a reasonable patch doing a good thing without any understandinding how
it affects (or even can affect in theory) some benchmark sounds like a bad idea.
We'll never learn this. It could be that the regression is caused my some
tiny alignment difference or something like this, so any other change can
trigger it too (I can be totally wrong here, but I don't have any better
explanation either).

Btw, do we have any similar tests?

Thanks!