From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: kernel test robot <ying.huang@linux.intel.com>
Cc: lkp@01.org, LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [lkp] [mm/vmstat] 6cdb18ad98: -8.5% will-it-scale.per_thread_ops
Date: Thu, 7 Jan 2016 12:23:01 +0100 [thread overview]
Message-ID: <20160107112301.GE4062@osiris> (raw)
In-Reply-To: <8760z7fl60.fsf@yhuang-dev.intel.com>
On Wed, Jan 06, 2016 at 11:20:55AM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit 6cdb18ad98a49f7e9b95d538a0614cde827404b8 ("mm/vmstat: fix overflow in mod_zone_page_state()")
>
>
> =========================================================================================
> compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase:
> gcc-4.9/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/ivb42/pread1/will-it-scale
>
> commit:
> cc28d6d80f6ab494b10f0e2ec949eacd610f66e3
> 6cdb18ad98a49f7e9b95d538a0614cde827404b8
>
> cc28d6d80f6ab494 6cdb18ad98a49f7e9b95d538a0
> ---------------- --------------------------
> %stddev %change %stddev
> \ | \
> 2733943 ± 0% -8.5% 2502129 ± 0% will-it-scale.per_thread_ops
> 3410 ± 0% -2.0% 3343 ± 0% will-it-scale.time.system_time
> 340.08 ± 0% +19.7% 406.99 ± 0% will-it-scale.time.user_time
> 69882822 ± 2% -24.3% 52926191 ± 5% cpuidle.C1-IVT.time
> 340.08 ± 0% +19.7% 406.99 ± 0% time.user_time
> 491.25 ± 6% -17.7% 404.25 ± 7% numa-vmstat.node0.nr_alloc_batch
> 2799 ± 20% -36.6% 1776 ± 0% numa-vmstat.node0.nr_mapped
> 630.00 ±140% +244.4% 2169 ± 1% numa-vmstat.node1.nr_inactive_anon
Hmm... this is odd. I did review all callers of mod_zone_page_state() and
couldn't find anything obvious that would go wrong after the int -> long
change.
I also tried the "pread1_threads" test case from
https://github.com/antonblanchard/will-it-scale.git
However the results seem to vary a lot after a reboot(!), at least on s390.
So I'm not sure if this is really a regression.
next prev parent reply other threads:[~2016-01-07 11:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 3:20 [lkp] [mm/vmstat] 6cdb18ad98: -8.5% will-it-scale.per_thread_ops kernel test robot
2016-01-07 11:23 ` Heiko Carstens [this message]
2016-01-08 5:24 ` [LKP] " Huang, Ying
2016-01-08 11:13 ` Heiko Carstens
2016-01-21 6:47 ` Huang, Ying
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=20160107112301.GE4062@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=torvalds@linux-foundation.org \
--cc=ying.huang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).