From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752805AbcAGLXK (ORCPT ); Thu, 7 Jan 2016 06:23:10 -0500 Received: from e06smtp05.uk.ibm.com ([195.75.94.101]:54147 "EHLO e06smtp05.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752007AbcAGLXH (ORCPT ); Thu, 7 Jan 2016 06:23:07 -0500 X-IBM-Helo: d06dlp02.portsmouth.uk.ibm.com X-IBM-MailFrom: heiko.carstens@de.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Thu, 7 Jan 2016 12:23:01 +0100 From: Heiko Carstens To: kernel test robot Cc: lkp@01.org, LKML , Andrew Morton , Christoph Lameter , Linus Torvalds Subject: Re: [lkp] [mm/vmstat] 6cdb18ad98: -8.5% will-it-scale.per_thread_ops Message-ID: <20160107112301.GE4062@osiris> References: <8760z7fl60.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8760z7fl60.fsf@yhuang-dev.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16010711-0021-0000-0000-0000055F303B Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.