public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Jirka Hladky <jhladky@redhat.com>
Cc: Rik van Riel <riel@redhat.com>, Aaron Lu <aaron.lu@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@01.org
Subject: Re: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local
Date: Thu, 31 Jul 2014 18:27:02 +0200	[thread overview]
Message-ID: <20140731162702.GZ19379@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <53DA6BDA.8080000@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3731 bytes --]

On Thu, Jul 31, 2014 at 06:16:26PM +0200, Jirka Hladky wrote:
> On 07/31/2014 05:57 PM, Peter Zijlstra wrote:
> >On Thu, Jul 31, 2014 at 12:42:41PM +0200, Peter Zijlstra wrote:
> >>On Tue, Jul 29, 2014 at 02:39:40AM -0400, Rik van Riel wrote:
> >>>On Tue, 29 Jul 2014 13:24:05 +0800
> >>>Aaron Lu <aaron.lu@intel.com> wrote:
> >>>
> >>>>FYI, we noticed the below changes on
> >>>>
> >>>>git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> >>>>commit a43455a1d572daf7b730fe12eb747d1e17411365 ("sched/numa: Ensure task_numa_migrate() checks the preferred node")
> >>>>
> >>>>ebe06187bf2aec1  a43455a1d572daf7b730fe12e
> >>>>---------------  -------------------------
> >>>>      94500 ~ 3%    +115.6%     203711 ~ 6%  ivb42/hackbench/50%-threads-pipe
> >>>>      67745 ~ 4%     +64.1%     111174 ~ 5%  lkp-snb01/hackbench/50%-threads-socket
> >>>>     162245 ~ 3%     +94.1%     314885 ~ 6%  TOTAL proc-vmstat.numa_hint_faults_local
> >>>Hi Aaron,
> >>>
> >>>Jirka Hladky has reported a regression with that changeset as
> >>>well, and I have already spent some time debugging the issue.
> >>Let me see if I can still find my SPECjbb2005 copy to see what that
> >>does.
> >Jirka, what kind of setup were you seeing SPECjbb regressions?
> >
> >I'm not seeing any on 2 sockets with a single SPECjbb instance, I'll go
> >check one instance per socket now.
> >
> >
> Peter, I'm seeing regressions for
> 
> SINGLE SPECjbb instance for number of warehouses being the same as total
> number of cores in the box.
> 
> Example: 4 NUMA node box, each CPU has 6 cores => biggest regression is for
> 24 warehouses.

IVB-EP: 2 node, 10 cores, 2 thread per core:

tip/master+origin/master:

     Warehouses               Thrput
              4               196781
              8               358064
             12               511318
             16               589251
             20               656123
             24               710789
             28               765426
             32               787059
             36               777899
           * 40               748568
                                    
Throughput      18258   

     Warehouses               Thrput
              4               201598
              8               363470
             12               512968
             16               584289
             20               605299
             24               720142
             28               776066
             32               791263
             36               776965
           * 40               760572
                                    
Throughput      18551   


tip/master+origin/master-a43455a1d57

                   SPEC scores                                                                                        
     Warehouses               Thrput
              4               198667
              8               362481
             12               503344
             16               582602
             20               647688
             24               731639
             28               786135
             32               794124
             36               774567
           * 40               757559
                                    
Throughput      18477  


Given that there's fairly large variance between the two runs with the
commit in, I'm not sure I can say there's a problem here.

The one run without the patch is more or less between the two runs with
the patch.

And doing this many runs takes ages, so I'm not tempted to either make
the runs longer or do more of them.

Lemme try on a 4 node box though, who knows.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-07-31 16:27 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <53d70ee6.JsUEmW5dWsv8dev+%fengguang.wu@intel.com>
2014-07-29  5:24 ` [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local Aaron Lu
2014-07-29  6:39   ` Rik van Riel
2014-07-29  8:17     ` Peter Zijlstra
2014-07-29 20:04       ` Rik van Riel
2014-07-30  2:14         ` Aaron Lu
2014-07-30 14:25           ` Rik van Riel
2014-07-31  5:04             ` Aaron Lu
2014-07-31  6:22               ` Rik van Riel
2014-07-31  6:53                 ` Aaron Lu
2014-07-31  6:42               ` Rik van Riel
2014-08-05 21:43               ` Rik van Riel
2014-07-31  8:33           ` Peter Zijlstra
2014-07-31  8:56             ` Aaron Lu
2014-07-31 10:42     ` Peter Zijlstra
2014-07-31 15:57       ` Peter Zijlstra
2014-07-31 16:16         ` Jirka Hladky
2014-07-31 16:27           ` Peter Zijlstra [this message]
2014-07-31 16:39             ` Jirka Hladky
2014-07-31 17:37               ` Peter Zijlstra
2014-08-01 15:02                 ` Peter Zijlstra
2014-08-01 20:46           ` Davidlohr Bueso
2014-08-01 20:48             ` Davidlohr Bueso
2014-08-01 21:30             ` Jirka Hladky
2014-08-02  4:17               ` Rik van Riel
2014-08-02  5:28                 ` Jirka Hladky
2014-08-02  4:26               ` Peter Zijlstra
2014-08-01  0:18       ` Davidlohr Bueso
2014-08-01  2:03       ` Aaron Lu
2014-08-01  4:03         ` Davidlohr Bueso
2014-08-01  7:29           ` Peter Zijlstra
2014-08-01  7:29         ` Peter Zijlstra
2014-07-31 23:58           ` Yuyang Du
2014-08-01  8:14           ` Fengguang Wu

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=20140731162702.GZ19379@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=aaron.lu@intel.com \
    --cc=jhladky@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=riel@redhat.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