linux-kernel - Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression

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: <20160603222109.GA12579@cmpxchg.org>
Date:	Fri, 3 Jun 2016 18:21:09 -0400
From:	Johannes Weiner <hannes@...xchg.org>
To:	kernel test robot <xiaolong.ye@...el.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, lkp@...org
Subject: Re: [lkp] [mm] 795ae7a0de: pixz.throughput -9.1% regression

On Thu, Jun 02, 2016 at 12:07:06PM -0400, Johannes Weiner wrote:
> Hi,
> 
> On Thu, Jun 02, 2016 at 02:45:07PM +0800, kernel test robot wrote:
> > FYI, we noticed pixz.throughput -9.1% regression due to commit:
> > 
> > commit 795ae7a0de6b834a0cc202aa55c190ef81496665 ("mm: scale kswapd watermarks in proportion to memory")
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > 
> > in testcase: pixz
> > on test machine: ivb43: 48 threads Ivytown Ivy Bridge-EP with 64G memory with following parameters: cpufreq_governor=performance/nr_threads=100%
> 
> Xiaolong, thanks for the report.
> 
> It looks like the regression stems from a change in NUMA placement:

Scratch that, I was misreading the test results. It's just fewer
allocations in general that happen during the fixed testing time.

I'm stumped by this report. All this patch does other than affect page
reclaim (which is not involved here) is increase the size of the round
robin batches in the fair zone allocator. That should *reduce* work in
the page allocator, if anything.

But I also keep failing to reproduce this - having tried it on the
third machine now - neither pixz nor will-it-scale/page_fault1 give me
that -8-9% regression:

4.5.0-02574-g3ed3a4f:
PIXZ-good.log:throughput: 39908733.604941994
PIXZ-good.log:throughput: 37067947.25049969
PIXZ-good.log:throughput: 38604938.39131216

4.5.0-02575-g795ae7a:
 PIXZ-bad.log:throughput: 39489120.87179377
 PIXZ-bad.log:throughput: 39307299.288432725
 PIXZ-bad.log:throughput: 38795994.3329781

Is this reliably reproducible with 3ed3a4f vs 795ae7a?

Could I ask you to retry the test with Linus's current head as well as
with 795ae7a reverted on top of it? (It's a clean revert.)

Thanks