All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: lkp@lists.01.org
Subject: Re: [mm, page_alloc] e6cbd7f2ef: pixz.throughput -5.1% regression
Date: Tue, 30 Aug 2016 11:06:33 +0100	[thread overview]
Message-ID: <20160830100633.GU8119@techsingularity.net> (raw)
In-Reply-To: <05540bdb-5b31-c75f-887f-64f60ce2580e@leemhuis.info>

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

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

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: kernel test robot <xiaolong.ye@intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Hillf Danton <hillf.zj@alibaba-inc.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Michal Hocko <mhocko@kernel.org>,
	Minchan Kim <minchan@kernel.org>, Rik van Riel <riel@surriel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@01.org
Subject: Re: [lkp] [mm, page_alloc] e6cbd7f2ef: pixz.throughput -5.1% regression
Date: Tue, 30 Aug 2016 11:06:33 +0100	[thread overview]
Message-ID: <20160830100633.GU8119@techsingularity.net> (raw)
In-Reply-To: <05540bdb-5b31-c75f-887f-64f60ce2580e@leemhuis.info>

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

  reply	other threads:[~2016-08-30 10:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-08  8:29 [mm, page_alloc] e6cbd7f2ef: pixz.throughput -5.1% regression kernel test robot
2016-08-08  8:29 ` [lkp] " kernel test robot
2016-08-28  9:51 ` Thorsten Leemhuis
2016-08-30 10:06   ` Mel Gorman [this message]
2016-08-30 10:06     ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160830100633.GU8119@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=lkp@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.