linux-kernel - Re: [lkp] [mm, page_alloc] e6cbd7f2ef: pixz.throughput -5.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] [day] [month] [year] [list]

Message-ID: <20160830100633.GU8119@techsingularity.net>
Date:   Tue, 30 Aug 2016 11:06:33 +0100
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Thorsten Leemhuis <regressions@...mhuis.info>
Cc:     kernel test robot <xiaolong.ye@...el.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Hillf Danton <hillf.zj@...baba-inc.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Michal Hocko <mhocko@...nel.org>,
        Minchan Kim <minchan@...nel.org>,
        Rik van Riel <riel@...riel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...org
Subject: Re: [lkp] [mm, page_alloc] e6cbd7f2ef: pixz.throughput -5.1%
 regression

On Sun, Aug 28, 2016 at 11:51:20AM +0200, Thorsten Leemhuis wrote:
> Lo! On 08.08.2016 10:29, kernel test robot wrote:
> > 
> > FYI, we noticed a -5.1% regression of pixz.throughput due to commit:
> > 
> > commit e6cbd7f2efb433d717af72aa8510a9db6f7a7e05 ("mm, page_alloc: remove fair zone allocation policy")
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > 
> > in testcase: pixz
> > on test machine: 48 threads Ivytown Ivy Bridge-EP with 64G memory
> > with following parameters:
> > 
> > 	nr_threads: 100%
> > 	cpufreq_governor: performance
> 
> Mel, this report made it to the regression list for 4.8, but it seems
> nothing happened after the initial report. Was it discussed (and maybe
> even fixed?) elsewhere? Or was it deemed not important enough? Should I
> drop it for the regression list?
> 

Drop it for the moment.

My expectation is that it's a relatively minor hazard. The removal of the
fair zone allocation policy is a shorter path which benefits a number
of workloads but also potentially changes the color of pages used in
microbenchmarks which can have a cache effect.  It's on my TODO list to
reproduce this exactly as LKP does but my own preliminary experiments using
pbzip (yes, it's different) on 4 machines showed gains on all 4 machines
so something relatively subtle is going on or it's machine specific.

-- 
Mel Gorman
SUSE Labs