From: Ye Xiaolong <xiaolong.ye@intel.com>
To: lkp@lists.01.org
Subject: Re: [x86/platform/UV] 71854cb812: will-it-scale.per_thread_ops -2.3% regression
Date: Thu, 27 Oct 2016 09:55:08 +0800 [thread overview]
Message-ID: <20161027015508.GG21890@yexl-desktop> (raw)
In-Reply-To: <alpine.DEB.2.20.1610251251400.4990@nanos>
[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]
On 10/25, Thomas Gleixner wrote:
>On Tue, 25 Oct 2016, kernel test robot wrote:
>> FYI, we noticed a -2.3% regression of will-it-scale.per_thread_ops due to commit:
>>
>> commit 71854cb812ec23bfe5f63d52217e6b9e6cb901f5 ("x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates")
>> https://github.com/0day-ci/linux Alex-Thorlton/x86-platform-UV-Fix-support-for-EFI_OLD_MEMMAP-after-BIOS-callback-updates/20161020-095215
>>
>> in testcase: will-it-scale
>> on test machine: 12 threads Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz with 6G memory
>
>This is completely bogus. That patch does not even affect anything outside
>of the SGI UV platform. And on your i7 system uv_bios_call() is definitely
>not invoked.
Yes, this is weird, the per_thread_ops change is small and should be run
to run variation, the actual significant change is will-it-scale.time.user_time
-27% decrease, but the patch seems not relevant, we can't interpret it. :(
We've tried to queue the jobs (4 times) for 71854cb812ec23bfe5f63d52217e6b9e6cb901f5 and v4.9-rc1
with new kconfig (added CONFIG_DEBUG_INFO_REDUCED), and result shows
user_time change is quite stable.
=========================================================================================
compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
gcc-6/performance/x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED/debian-x86_64-2016-08-31.cgz/wsm/read2/will-it-scale
commit:
v4.9-rc1
71854cb812ec23bfe5f63d52217e6b9e6cb901f5
v4.9-rc1 71854cb812ec23bfe5f63d5221
---------------- --------------------------
%stddev %change %stddev
\ | \
1670068 ± 0% -3.8% 1606650 ± 1% will-it-scale.per_thread_ops
9749 ± 2% +1328.0% 139222 ±105% will-it-scale.time.involuntary_context_switches
981.29 ± 0% +2.2% 1002 ± 0% will-it-scale.time.system_time
81.78 ± 0% -26.9% 59.74 ± 0% will-it-scale.time.user_time
32894 ± 0% -3.1% 31863 ± 2% vmstat.system.cs
9749 ± 2% +1328.0% 139222 ±105% time.involuntary_context_switches
380917 ± 2% -10.2% 341970 ± 3% sched_debug.cpu.avg_idle.avg
89166 ± 33% -73.4% 23731 ± 29% sched_debug.cpu.avg_idle.min
16.38 ± 10% -32.3% 11.08 ± 18% sched_debug.cpu.nr_uninterruptible.max
0.29 ± 1% +32.6% 0.38 ± 1% perf-stat.branch-miss-rate%
2.897e+09 ± 1% +33.5% 3.867e+09 ± 2% perf-stat.branch-misses
10084878 ± 0% -3.2% 9761852 ± 2% perf-stat.context-switches
0.00 ± 7% -9.3% 0.00 ± 1% perf-stat.dTLB-store-miss-rate%
33489012 ± 7% -9.2% 30416429 ± 1% perf-stat.dTLB-store-misses
Thanks,
Xiaolong
>
>I appreciate your effort, but posting such obviously bogus results does not
>make people more confident in your testing efforts.
>
>Thanks,
>
> tglx
WARNING: multiple messages have this Message-ID (diff)
From: Ye Xiaolong <xiaolong.ye@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Alex Thorlton <athorlton@sgi.com>,
linux-kernel@vger.kernel.org, Mike Travis <travis@sgi.com>,
Russ Anderson <rja@sgi.com>, Dimitri Sivanich <sivanich@sgi.com>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Matt Fleming <matt@codeblueprint.co.uk>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
x86@kernel.org, lkp@01.org
Subject: Re: [lkp] [x86/platform/UV] 71854cb812: will-it-scale.per_thread_ops -2.3% regression
Date: Thu, 27 Oct 2016 09:55:08 +0800 [thread overview]
Message-ID: <20161027015508.GG21890@yexl-desktop> (raw)
In-Reply-To: <alpine.DEB.2.20.1610251251400.4990@nanos>
On 10/25, Thomas Gleixner wrote:
>On Tue, 25 Oct 2016, kernel test robot wrote:
>> FYI, we noticed a -2.3% regression of will-it-scale.per_thread_ops due to commit:
>>
>> commit 71854cb812ec23bfe5f63d52217e6b9e6cb901f5 ("x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates")
>> https://github.com/0day-ci/linux Alex-Thorlton/x86-platform-UV-Fix-support-for-EFI_OLD_MEMMAP-after-BIOS-callback-updates/20161020-095215
>>
>> in testcase: will-it-scale
>> on test machine: 12 threads Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz with 6G memory
>
>This is completely bogus. That patch does not even affect anything outside
>of the SGI UV platform. And on your i7 system uv_bios_call() is definitely
>not invoked.
Yes, this is weird, the per_thread_ops change is small and should be run
to run variation, the actual significant change is will-it-scale.time.user_time
-27% decrease, but the patch seems not relevant, we can't interpret it. :(
We've tried to queue the jobs (4 times) for 71854cb812ec23bfe5f63d52217e6b9e6cb901f5 and v4.9-rc1
with new kconfig (added CONFIG_DEBUG_INFO_REDUCED), and result shows
user_time change is quite stable.
=========================================================================================
compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
gcc-6/performance/x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED/debian-x86_64-2016-08-31.cgz/wsm/read2/will-it-scale
commit:
v4.9-rc1
71854cb812ec23bfe5f63d52217e6b9e6cb901f5
v4.9-rc1 71854cb812ec23bfe5f63d5221
---------------- --------------------------
%stddev %change %stddev
\ | \
1670068 ± 0% -3.8% 1606650 ± 1% will-it-scale.per_thread_ops
9749 ± 2% +1328.0% 139222 ±105% will-it-scale.time.involuntary_context_switches
981.29 ± 0% +2.2% 1002 ± 0% will-it-scale.time.system_time
81.78 ± 0% -26.9% 59.74 ± 0% will-it-scale.time.user_time
32894 ± 0% -3.1% 31863 ± 2% vmstat.system.cs
9749 ± 2% +1328.0% 139222 ±105% time.involuntary_context_switches
380917 ± 2% -10.2% 341970 ± 3% sched_debug.cpu.avg_idle.avg
89166 ± 33% -73.4% 23731 ± 29% sched_debug.cpu.avg_idle.min
16.38 ± 10% -32.3% 11.08 ± 18% sched_debug.cpu.nr_uninterruptible.max
0.29 ± 1% +32.6% 0.38 ± 1% perf-stat.branch-miss-rate%
2.897e+09 ± 1% +33.5% 3.867e+09 ± 2% perf-stat.branch-misses
10084878 ± 0% -3.2% 9761852 ± 2% perf-stat.context-switches
0.00 ± 7% -9.3% 0.00 ± 1% perf-stat.dTLB-store-miss-rate%
33489012 ± 7% -9.2% 30416429 ± 1% perf-stat.dTLB-store-misses
Thanks,
Xiaolong
>
>I appreciate your effort, but posting such obviously bogus results does not
>make people more confident in your testing efforts.
>
>Thanks,
>
> tglx
next prev parent reply other threads:[~2016-10-27 1:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-20 1:48 [PATCH v2] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates Alex Thorlton
2016-10-20 12:26 ` Matt Fleming
2016-10-21 5:48 ` [tip:x86/urgent] " tip-bot for Alex Thorlton
2016-10-25 6:46 ` [x86/platform/UV] 71854cb812: will-it-scale.per_thread_ops -2.3% regression kernel test robot
2016-10-25 6:46 ` [lkp] " kernel test robot
2016-10-25 10:57 ` Thomas Gleixner
2016-10-25 10:57 ` [lkp] " Thomas Gleixner
2016-10-27 1:55 ` Ye Xiaolong [this message]
2016-10-27 1:55 ` Ye Xiaolong
2016-10-27 22:37 ` Thomas Gleixner
2016-10-27 22:37 ` [lkp] " Thomas Gleixner
2016-10-31 5:41 ` Fengguang Wu
2016-10-31 5:41 ` [LKP] [lkp] " Fengguang Wu
2016-10-31 18:19 ` Thomas Gleixner
2016-10-31 18:19 ` [LKP] [lkp] " Thomas Gleixner
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=20161027015508.GG21890@yexl-desktop \
--to=xiaolong.ye@intel.com \
--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.