public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ye Xiaolong <xiaolong.ye@intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Minchan Kim <minchan@kernel.org>,
	Hillf Danton <hillf.zj@alibaba-inc.com>,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@01.org
Subject: Re: [lkp-robot] [mm, vmscan]  5e56dfbd83:  fsmark.files_per_sec -11.1% regression
Date: Thu, 23 Feb 2017 09:27:34 +0800	[thread overview]
Message-ID: <20170223012734.GB31776@yexl-desktop> (raw)
In-Reply-To: <20170207144315.GS5065@dhcp22.suse.cz>

Hi, Michal

On 02/07, Michal Hocko wrote:
[snip]
>Could you retest with a single NUMA node? I am not familiar with the
>benchmark enough to judge it was set up properly for a NUMA machine.

I've retested the commit with a single NUMA node via "numactl -m 0 fs_mark xxx",
and it did help recover the performance back.

Here is the comparison:

commit/compiler/cpufreq_governor/disk/filesize/fs/iterations/kconfig/md/nr_threads/rootfs/sync_method/tbox_group/test_size/testcase:
  5e56dfbd837421b7fa3c6c06018c6701e2704917/gcc-6/performance/3HDD/4M/btrfs/1/x86_64-rhel-7.2/RAID5/64/debian-x86_64-2016-08-31.cgz/NoSync/ivb44/130G/fsmark
   
(with a single NUMA node)	    (2 NUMA nodes)
-------------------------------------------------------------------- 
       fail:runs   %reproduction    fail:runs
           |              |             |    
         %stddev      %change         %stddev
             \           |                \  
     57.60 ±  0%      -11.1%      51.20 ±  0%  fsmark.files_per_sec
    607.84 ±  0%       +9.0%     662.24 ±  1%  fsmark.time.elapsed_time
    607.84 ±  0%       +9.0%     662.24 ±  1%  fsmark.time.elapsed_time.max
     14317 ±  6%      -12.2%      12568 ±  7%  fsmark.time.involuntary_context_switches
      1864 ±  0%       +0.5%       1873 ±  0%  fsmark.time.maximum_resident_set_size
     12425 ±  0%      +23.3%      15320 ±  3%  fsmark.time.minor_page_faults
     33.00 ±  3%      -33.9%      21.80 ±  1%  fsmark.time.percent_of_cpu_this_job_got
    203.49 ±  3%      -28.1%     146.31 ±  1%  fsmark.time.system_time
    605701 ±  0%       +3.6%     627486 ±  0%  fsmark.time.voluntary_context_switches
    307106 ±  2%      +20.2%     368992 ±  9%  interrupts.CAL:Function_call_interrupts
    183040 ±  0%      +23.2%     225559 ±  3%  softirqs.BLOCK
     12203 ± 57%     +236.4%      41056 ±103%  softirqs.NET_RX
    186118 ±  0%      +21.9%     226922 ±  2%  softirqs.TASKLET
     14317 ±  6%      -12.2%      12568 ±  7%  time.involuntary_context_switches
     12425 ±  0%      +23.3%      15320 ±  3%  time.minor_page_faults
     33.00 ±  3%      -33.9%      21.80 ±  1%  time.percent_of_cpu_this_job_got
    203.49 ±  3%      -28.1%     146.31 ±  1%  time.system_time
      3.47 ±  3%      -13.0%       3.02 ±  1%  turbostat.%Busy
     99.60 ±  1%       -9.6%      90.00 ±  1%  turbostat.Avg_MHz
     78.69 ±  1%       +1.7%      80.01 ±  0%  turbostat.CorWatt
      3.56 ± 61%      -91.7%       0.30 ± 76%  turbostat.Pkg%pc2
    207790 ±  0%       -8.2%     190654 ±  1%  vmstat.io.bo
  30667691 ±  0%      +65.9%   50890669 ±  1%  vmstat.memory.cache
  34549892 ±  0%      -58.4%   14378939 ±  4%  vmstat.memory.free
      6768 ±  0%       -1.3%       6681 ±  1%  vmstat.system.cs
 1.089e+10 ±  2%      +13.4%  1.236e+10 ±  3%  cpuidle.C1E-IVT.time
  11475304 ±  2%      +13.4%   13007849 ±  3%  cpuidle.C1E-IVT.usage
   2.7e+09 ±  6%      +13.2%  3.057e+09 ±  3%  cpuidle.C3-IVT.time
   2954294 ±  6%      +14.3%    3375966 ±  3%  cpuidle.C3-IVT.usage
  96963295 ± 14%      +17.5%  1.139e+08 ± 12%  cpuidle.POLL.time
      8761 ±  7%      +17.6%      10299 ±  9%  cpuidle.POLL.usage
  30454483 ±  0%      +66.4%   50666102 ±  1%  meminfo.Cached

Do you see what's happening? Or is there anything we can do to improve fsmark
benchmark setup to make it more reasonable?

Thanks,
Xiaolong

>-- 
>Michal Hocko
>SUSE Labs

  reply	other threads:[~2017-02-23  1:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-23  1:26 [lkp-robot] [mm, vmscan] 5e56dfbd83: fsmark.files_per_sec -11.1% regression kernel test robot
2017-01-24 13:44 ` Michal Hocko
2017-01-25  4:27   ` Ye Xiaolong
2017-01-26  9:13     ` Michal Hocko
2017-02-04  8:16       ` Ye Xiaolong
2017-02-06  8:12         ` Michal Hocko
2017-02-07  2:22           ` Ye Xiaolong
2017-02-07 14:43             ` Michal Hocko
2017-02-23  1:27               ` Ye Xiaolong [this message]
2017-02-23  7:35                 ` Michal Hocko
2017-02-23 15:19                   ` 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=20170223012734.GB31776@yexl-desktop \
    --to=xiaolong.ye@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox