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
next prev parent 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