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 --]
next prev parent 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