can not find one. do you have rt? maybe we could queue a bisect to check.
> -----Original Message-----
> From: Xing Zhengjun <zhengjun.xing(a)linux.intel.com>
> Sent: Friday, February 5, 2021 10:09 AM
> To: Sang, Oliver <oliver.sang(a)intel.com>; Li, Philip
> Cc: lkp <lkp(a)lists.01.org>
> Subject: Fwd: [LKP] Re: [mm] 10befea91b: hackbench.throughput -62.4%
> Hi Oliver,
> From 286e04b8ed7a0427 to 3de7d4f25a7438f09fef4e71ef1 there are two
> regressions for process mode :
> 1) 286e04b8ed7a0427 to 10befea91b61c4e2c2d1df06a2e (-62.4% regression)
> 2) 10befea91b61c4e2c2d1df06a2e to d3921cb8be29ce5668c64e23ffd (-22.3%
> For regression 1), 0-day has reported it. For regression 2), Do we report any
> regression? Thanks.
> -------- Forwarded Message --------
> Subject: Re: [LKP] Re: [mm] 10befea91b: hackbench.throughput -62.4%
> Date: Thu, 4 Feb 2021 17:04:57 -0800
> From: Roman Gushchin <guro(a)fb.com>
> To: Xing Zhengjun <zhengjun.xing(a)linux.intel.com>
> CC: Johannes Weiner <hannes(a)cmpxchg.org>, Andrew Morton
> <akpm(a)linux-foundation.org>, Vlastimil Babka <vbabka(a)suse.cz>, Shakeel
> Butt <shakeelb(a)google.com>, Christoph Lameter <cl(a)linux.com>, Michal
> Hocko <mhocko(a)kernel.org>, Tejun Heo <tj(a)kernel.org>, Linus Torvalds
> <torvalds(a)linux-foundation.org>, LKML <linux-kernel(a)vger.kernel.org>,
> lkp(a)lists.01.org, lkp(a)intel.com
> On Thu, Feb 04, 2021 at 01:19:47PM +0800, Xing Zhengjun wrote:
> > On 2/3/2021 10:49 AM, Roman Gushchin wrote:
> > > On Tue, Feb 02, 2021 at 04:18:27PM +0800, Xing, Zhengjun wrote:
> > > > On 1/14/2021 11:18 AM, Roman Gushchin wrote:
> > > > > On Thu, Jan 14, 2021 at 10:51:51AM +0800, kernel test robot
> > > > > > Greeting,
> > > > > >
> > > > > > FYI, we noticed a -62.4% regression of hackbench.throughput
> > > > > Hi!
> > > > >
> > > > > Commit "mm: memcg/slab: optimize objcg stock draining"
> in the mm tree,
> > > > > so no stable hash) should improve the hackbench regression.
> > > > The commit has been merged into Linux mainline :
> > > > 3de7d4f25a7438f09fef4e71ef111f1805cd8e7c ("mm: memcg/slab:
> optimize objcg
> > > > stock draining")
> > > > I test the regression still existed.
> > > Hm, so in your setup it's about the same with and without this commit?
> > >
> > > It's strange because I've received a letter stating a 45.2%
> > > https://lkml.org/lkml/2021/1/27/83
> > They are different test cases, 45.2% improvement test case run in
> mode, -62.4% regression test case run in "process" mode.
> Thank you for the clarification!
> > From 286e04b8ed7a0427 to 3de7d4f25a7438f09fef4e71ef1 there are two
> regressions for process mode :
> > 1) 286e04b8ed7a0427 to 10befea91b61c4e2c2d1df06a2e (-62.4% regression)
> > 2) 10befea91b61c4e2c2d1df06a2e to d3921cb8be29ce5668c64e23ffd (-22.3%
> > 3de7d4f25a7438f09fef4e71ef111f1805cd8e7c only fix the regression 2) , so
> the value of "hackbench.throughput" for 3de7d4f25a7438f09fef4e71ef1(71824)
> and 10befea91b61c4e2c2d1df06a2e (72220) is very closed.
> Ok, it seems that 1) is caused by switching to per-object
> accounting/stats of slab memory.
> I don't now anything about 2). There are 38326 commits in between. Do
> you know which commits
> are causing it?
> I believe that 3de7d4f25a74 partially fixes regression 1).
> I'll take a look what we can do here.
> Some regression could be unavoidable: we're doing more precise
> accounting, but it requires
> more work. As a compensation we're getting major benefits like saving
> over 40% of
> the slab memory and having less fragmentation.
> But hopefully we can make it smaller.