From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932128AbcAHLNc (ORCPT ); Fri, 8 Jan 2016 06:13:32 -0500 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:53358 "EHLO e06smtp17.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751780AbcAHLNb (ORCPT ); Fri, 8 Jan 2016 06:13:31 -0500 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: heiko.carstens@de.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Fri, 8 Jan 2016 12:13:23 +0100 From: Heiko Carstens To: "Huang, Ying" Cc: Christoph Lameter , Linus Torvalds , Andrew Morton , lkp@01.org, LKML Subject: Re: [LKP] [lkp] [mm/vmstat] 6cdb18ad98: -8.5% will-it-scale.per_thread_ops Message-ID: <20160108111323.GA3927@osiris> References: <8760z7fl60.fsf@yhuang-dev.intel.com> <20160107112301.GE4062@osiris> <87mvsgfxtd.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mvsgfxtd.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: 16010811-0005-0000-0000-000009F18DE6 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 08, 2016 at 01:24:30PM +0800, Huang, Ying wrote: > Heiko Carstens writes: > > > 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. > > The test is quite stable for my side. We run the test case 7 times for > your commit and its parent. The standard variation is very low. > > you commit: > > [2493136, 2510964, 2508784, 2495632, 2506735, 2503016, 2510121] > > parent commit: > > [2735669, 2719566, 2739052, 2741485, 2735152, 2739356, 2739125] > > The test result is stable for bisection too. The below figure show the > results of good commits and bad commits. The distance between is quite > big. And the variation is quite small. Ok, so it seems to be quite stable on your machine across reboots. I have to admit I still cannot make much sense of this. Is the "pread1" testcase the only one that performs worse, or are there more? Also could you please provide the output of /proc/zoneinfo and the output of "perf top" of the good/bad cases? Maybe that might help to figure out what is happening. > FYI, I test your patch on x86 platform. I have no s390 system. Sure, I wouldn't expect that.