From: "ying.huang@intel.com" <ying.huang@intel.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
LKML <linux-kernel@vger.kernel.org>,
lkp@lists.01.org, lkp@intel.com, feng.tang@intel.com,
zhengjun.xing@linux.intel.com, fengwei.yin@intel.com,
aubrey.li@linux.intel.com, yu.c.chen@intel.com,
kernel test robot <oliver.sang@intel.com>
Subject: Re: [sched/fair] 2cfb7a1b03: stress-ng.fstat.ops_per_sec -19.8% regression
Date: Fri, 22 Apr 2022 16:11:52 +0800 [thread overview]
Message-ID: <8335c2c389c2aee51d91a79bee977f4df6f8fb77.camel@intel.com> (raw)
In-Reply-To: <d397577e14a5ca04f883d866e4ef1a1fddf19c8d.camel@intel.com>
Hi, Mel,
On Wed, 2022-04-20 at 14:24 +0800, ying.huang@intel.com wrote:
> Hi, Mel,
>
> On Mon, 2022-04-18 at 22:18 +0800, kernel test robot wrote:
> > (please be noted we reported "[sched/fair] 2cfb7a1b03: fsmark.files_per_sec
> > -26.2% regression" at
> > https://lore.kernel.org/all/20220303153108.GC14527@xsang-OptiPlex-9020/
> > when this is still on branch:
> > commit: 2cfb7a1b031b0e816af7a6ee0c6ab83b0acdf05a ("sched/fair: Improve consistency of allowed NUMA balance calculations")
> > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git sched/core
> >
> > now we noticed the similar performance changes as well as some others are
> > still existing on mainline, so report this again for information)
> >
> >
> > Greeting,
> >
> > FYI, we noticed a -19.8% regression of stress-ng.fstat.ops_per_sec due to commit:
> >
> >
> > commit: 2cfb7a1b031b0e816af7a6ee0c6ab83b0acdf05a ("sched/fair: Improve consistency of allowed NUMA balance calculations")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> > in testcase: stress-ng
> > on test machine: 96 threads 2 sockets Ice Lake with 256G memory
> > with following parameters:
> >
> > nr_threads: 10%
> > disk: 1HDD
> > testtime: 60s
> > fs: f2fs
> > class: filesystem
> > test: fstat
> > cpufreq_governor: performance
> > ucode: 0xb000280
> >
> >
> > In addition to that, the commit also has significant impact on the following tests:
> >
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | phoronix-test-suite: phoronix-test-suite.neatbench.CPU.fps 12.5% improvement |
> > > test machine | 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 512G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | option_a=CPU |
> > > | test=neatbench-1.0.4 |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | phoronix-test-suite: phoronix-test-suite.neatbench.All.fps 15.2% improvement |
> > > test machine | 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 512G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | option_a=All (CPU + GPU) |
> > > | test=neatbench-1.0.4 |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | fsmark: fsmark.files_per_sec -9.9% regression |
> > > test machine | 192 threads 4 sockets Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | disk=1BRD_48G |
> > > | filesize=4M |
> > > | fs=f2fs |
> > > | iterations=1x |
> > > | nr_threads=64t |
> > > | sync_method=fsyncBeforeClose |
> > > | test_size=24G |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | fsmark: fsmark.files_per_sec -26.2% regression |
> > > test machine | 192 threads 4 sockets Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | disk=1BRD_48G |
> > > | filesize=4M |
> > > | fs=ext4 |
> > > | iterations=1x |
> > > | nr_threads=64t |
> > > | sync_method=NoSync |
> > > | test_size=24G |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | stress-ng: stress-ng.fstat.ops_per_sec -20.1% regression |
> > > test machine | 96 threads 2 sockets Ice Lake with 256G memory |
> > > test parameters | class=filesystem |
> > > | cpufreq_governor=performance |
> > > | disk=1HDD |
> > > | fs=xfs |
> > > | nr_threads=10% |
> > > | test=fstat |
> > > | testtime=60s |
> > > | ucode=0xb000280 |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | fsmark: fsmark.files_per_sec -16.3% regression |
> > > test machine | 192 threads 4 sockets Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | disk=1BRD_48G |
> > > | filesize=4M |
> > > | fs=ext4 |
> > > | iterations=1x |
> > > | nr_threads=64t |
> > > | sync_method=fsyncBeforeClose |
> > > | test_size=24G |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | stress-ng: stress-ng.fstat.ops_per_sec -20.2% regression |
> > > test machine | 96 threads 2 sockets Ice Lake with 256G memory |
> > > test parameters | class=filesystem |
> > > | cpufreq_governor=performance |
> > > | disk=1HDD |
> > > | fs=xfs |
> > > | nr_threads=10% |
> > > | test=fstat |
> > > | testtime=60s |
> > > | ucode=0xb000280 |
> > +------------------+-------------------------------------------------------------------------------------+
> >
>
> When I worked on the following regression report,
>
> https://lore.kernel.org/lkml/87tuc7fp9k.fsf@yhuang6-desk2.ccr.corp.intel.com/
>
> I found stress-ng throughput will regress if the tasks are distrubuted
> more evenly among NUMA nodes. So for this regression, I re-tested with
> mpstat per node statistics. The results are as follows,
>
> mpstat.node.0.user% mpstat.node.1.user% mpstat.node.0.sys% mpstat.node.1.sys%
> 889c5d60fb 3.04 2.65 30.0 25.8
> 2cfb7a1b03 2.39 2.28 31.2 28.9
>
> It can be found that the task are balanced better with the commit
> 2cfb7a1b03. So I think the regression isn't a real problem.
I think stress-ng isn't a good workload to evaluate the effect of this
patch. Can you teach me which workloads are appropriate?
Best Regards,
Huang, Ying
WARNING: multiple messages have this Message-ID (diff)
From: ying.huang@intel.com
To: lkp@lists.01.org
Subject: Re: [sched/fair] 2cfb7a1b03: stress-ng.fstat.ops_per_sec -19.8% regression
Date: Fri, 22 Apr 2022 16:11:52 +0800 [thread overview]
Message-ID: <8335c2c389c2aee51d91a79bee977f4df6f8fb77.camel@intel.com> (raw)
In-Reply-To: <d397577e14a5ca04f883d866e4ef1a1fddf19c8d.camel@intel.com>
[-- Attachment #1: Type: text/plain, Size: 11294 bytes --]
Hi, Mel,
On Wed, 2022-04-20 at 14:24 +0800, ying.huang(a)intel.com wrote:
> Hi, Mel,
>
> On Mon, 2022-04-18 at 22:18 +0800, kernel test robot wrote:
> > (please be noted we reported "[sched/fair] 2cfb7a1b03: fsmark.files_per_sec
> > -26.2% regression" at
> > https://lore.kernel.org/all/20220303153108.GC14527(a)xsang-OptiPlex-9020/
> > when this is still on branch:
> > commit: 2cfb7a1b031b0e816af7a6ee0c6ab83b0acdf05a ("sched/fair: Improve consistency of allowed NUMA balance calculations")
> > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git sched/core
> >
> > now we noticed the similar performance changes as well as some others are
> > still existing on mainline, so report this again for information)
> >
> >
> > Greeting,
> >
> > FYI, we noticed a -19.8% regression of stress-ng.fstat.ops_per_sec due to commit:
> >
> >
> > commit: 2cfb7a1b031b0e816af7a6ee0c6ab83b0acdf05a ("sched/fair: Improve consistency of allowed NUMA balance calculations")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> > in testcase: stress-ng
> > on test machine: 96 threads 2 sockets Ice Lake with 256G memory
> > with following parameters:
> >
> > nr_threads: 10%
> > disk: 1HDD
> > testtime: 60s
> > fs: f2fs
> > class: filesystem
> > test: fstat
> > cpufreq_governor: performance
> > ucode: 0xb000280
> >
> >
> > In addition to that, the commit also has significant impact on the following tests:
> >
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | phoronix-test-suite: phoronix-test-suite.neatbench.CPU.fps 12.5% improvement |
> > > test machine | 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 512G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | option_a=CPU |
> > > | test=neatbench-1.0.4 |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | phoronix-test-suite: phoronix-test-suite.neatbench.All.fps 15.2% improvement |
> > > test machine | 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 512G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | option_a=All (CPU + GPU) |
> > > | test=neatbench-1.0.4 |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | fsmark: fsmark.files_per_sec -9.9% regression |
> > > test machine | 192 threads 4 sockets Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | disk=1BRD_48G |
> > > | filesize=4M |
> > > | fs=f2fs |
> > > | iterations=1x |
> > > | nr_threads=64t |
> > > | sync_method=fsyncBeforeClose |
> > > | test_size=24G |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | fsmark: fsmark.files_per_sec -26.2% regression |
> > > test machine | 192 threads 4 sockets Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | disk=1BRD_48G |
> > > | filesize=4M |
> > > | fs=ext4 |
> > > | iterations=1x |
> > > | nr_threads=64t |
> > > | sync_method=NoSync |
> > > | test_size=24G |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | stress-ng: stress-ng.fstat.ops_per_sec -20.1% regression |
> > > test machine | 96 threads 2 sockets Ice Lake with 256G memory |
> > > test parameters | class=filesystem |
> > > | cpufreq_governor=performance |
> > > | disk=1HDD |
> > > | fs=xfs |
> > > | nr_threads=10% |
> > > | test=fstat |
> > > | testtime=60s |
> > > | ucode=0xb000280 |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | fsmark: fsmark.files_per_sec -16.3% regression |
> > > test machine | 192 threads 4 sockets Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 192G memory |
> > > test parameters | cpufreq_governor=performance |
> > > | disk=1BRD_48G |
> > > | filesize=4M |
> > > | fs=ext4 |
> > > | iterations=1x |
> > > | nr_threads=64t |
> > > | sync_method=fsyncBeforeClose |
> > > | test_size=24G |
> > > | ucode=0x500320a |
> > +------------------+-------------------------------------------------------------------------------------+
> > > testcase: change | stress-ng: stress-ng.fstat.ops_per_sec -20.2% regression |
> > > test machine | 96 threads 2 sockets Ice Lake with 256G memory |
> > > test parameters | class=filesystem |
> > > | cpufreq_governor=performance |
> > > | disk=1HDD |
> > > | fs=xfs |
> > > | nr_threads=10% |
> > > | test=fstat |
> > > | testtime=60s |
> > > | ucode=0xb000280 |
> > +------------------+-------------------------------------------------------------------------------------+
> >
>
> When I worked on the following regression report,
>
> https://lore.kernel.org/lkml/87tuc7fp9k.fsf(a)yhuang6-desk2.ccr.corp.intel.com/
>
> I found stress-ng throughput will regress if the tasks are distrubuted
> more evenly among NUMA nodes. So for this regression, I re-tested with
> mpstat per node statistics. The results are as follows,
>
> mpstat.node.0.user% mpstat.node.1.user% mpstat.node.0.sys% mpstat.node.1.sys%
> 889c5d60fb 3.04 2.65 30.0 25.8
> 2cfb7a1b03 2.39 2.28 31.2 28.9
>
> It can be found that the task are balanced better with the commit
> 2cfb7a1b03. So I think the regression isn't a real problem.
I think stress-ng isn't a good workload to evaluate the effect of this
patch. Can you teach me which workloads are appropriate?
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2022-04-22 8:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-18 14:18 [sched/fair] 2cfb7a1b03: stress-ng.fstat.ops_per_sec -19.8% regression kernel test robot
2022-04-18 14:18 ` kernel test robot
2022-04-20 6:24 ` ying.huang
2022-04-20 6:24 ` ying.huang
2022-04-22 8:11 ` ying.huang [this message]
2022-04-22 8:11 ` ying.huang
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=8335c2c389c2aee51d91a79bee977f4df6f8fb77.camel@intel.com \
--to=ying.huang@intel.com \
--cc=aubrey.li@linux.intel.com \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=gautham.shenoy@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=mgorman@techsingularity.net \
--cc=oliver.sang@intel.com \
--cc=peterz@infradead.org \
--cc=yu.c.chen@intel.com \
--cc=zhengjun.xing@linux.intel.com \
/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.