From: Jirka Hladky <jhladky@redhat.com>
To: lkp@lists.01.org
Subject: Re: [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local
Date: Fri, 01 Aug 2014 23:30:34 +0200 [thread overview]
Message-ID: <53DC06FA.8030104@redhat.com> (raw)
In-Reply-To: <1406926000.16021.6.camel@buesod1.americas.hpqcorp.net>
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
On 08/01/2014 10:46 PM, Davidlohr Bueso wrote:
> On Thu, 2014-07-31 at 18:16 +0200, Jirka Hladky wrote:
>> 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.
> By looking at your graph, that's around a 10% difference.
>
> So I'm not seeing anywhere near as bad a regression on a 80-core box.
> Testing single with 80 warehouses, I get:
>
> tip/master baseline:
> 677476.36 bops
> 705826.70 bops
> 704870.87 bops
> 681741.20 bops
> 707014.59 bops
>
> Avg: 695385.94 bops
>
> tip/master + patch (NUMA_SCALE/8 variant):
> 698242.66 bops
> 693873.18 bops
> 707852.28 bops
> 691785.96 bops
> 747206.03 bopsthis
>
> Avg: 707792.022 bops
>
> So both these are pretty similar, however, when reverting, on avg we
> increase the amount of bops a mere ~4%:
>
> tip/master + reverted:
> 778416.02 bops
> 702602.62 bops
> 712557.32 bops
> 713982.90 bops
> 783300.36 bops
>
> Avg: 738171.84 bops
>
> Are there perhaps any special specjbb options you are using?
>
I see the regression only on this box. It has 4 "Ivy Bridge-EX" Xeon
E7-4890 v2 CPUs.
http://ark.intel.com/products/75251
http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors#.22Ivy_Bridge-EX.22_.2822_nm.29_Expandable_2
Please rerun the test on box with Ivy Bridge CPUs. It seems that older
CPU generations are not affected.
Thanks
Jirka
WARNING: multiple messages have this Message-ID (diff)
From: Jirka Hladky <jhladky@redhat.com>
To: Davidlohr Bueso <davidlohr@hp.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
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: Fri, 01 Aug 2014 23:30:34 +0200 [thread overview]
Message-ID: <53DC06FA.8030104@redhat.com> (raw)
In-Reply-To: <1406926000.16021.6.camel@buesod1.americas.hpqcorp.net>
On 08/01/2014 10:46 PM, Davidlohr Bueso wrote:
> On Thu, 2014-07-31 at 18:16 +0200, Jirka Hladky wrote:
>> 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.
> By looking at your graph, that's around a 10% difference.
>
> So I'm not seeing anywhere near as bad a regression on a 80-core box.
> Testing single with 80 warehouses, I get:
>
> tip/master baseline:
> 677476.36 bops
> 705826.70 bops
> 704870.87 bops
> 681741.20 bops
> 707014.59 bops
>
> Avg: 695385.94 bops
>
> tip/master + patch (NUMA_SCALE/8 variant):
> 698242.66 bops
> 693873.18 bops
> 707852.28 bops
> 691785.96 bops
> 747206.03 bopsthis
>
> Avg: 707792.022 bops
>
> So both these are pretty similar, however, when reverting, on avg we
> increase the amount of bops a mere ~4%:
>
> tip/master + reverted:
> 778416.02 bops
> 702602.62 bops
> 712557.32 bops
> 713982.90 bops
> 783300.36 bops
>
> Avg: 738171.84 bops
>
> Are there perhaps any special specjbb options you are using?
>
I see the regression only on this box. It has 4 "Ivy Bridge-EX" Xeon
E7-4890 v2 CPUs.
http://ark.intel.com/products/75251
http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors#.22Ivy_Bridge-EX.22_.2822_nm.29_Expandable_2
Please rerun the test on box with Ivy Bridge CPUs. It seems that older
CPU generations are not affected.
Thanks
Jirka
next prev parent reply other threads:[~2014-08-01 21:30 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53d70ee6.JsUEmW5dWsv8dev+%fengguang.wu@intel.com>
2014-07-29 5:24 ` [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local Aaron Lu
2014-07-29 5:24 ` [LKP] " Aaron Lu
2014-07-29 6:39 ` Rik van Riel
2014-07-29 6:39 ` [LKP] " Rik van Riel
2014-07-29 8:17 ` Peter Zijlstra
2014-07-29 8:17 ` [LKP] " Peter Zijlstra
2014-07-29 20:04 ` Rik van Riel
2014-07-29 20:04 ` [LKP] " Rik van Riel
2014-07-30 2:14 ` Aaron Lu
2014-07-30 2:14 ` [LKP] " Aaron Lu
2014-07-30 14:25 ` Rik van Riel
2014-07-30 14:25 ` [LKP] " Rik van Riel
2014-07-31 5:04 ` Aaron Lu
2014-07-31 5:04 ` [LKP] " Aaron Lu
2014-07-31 6:22 ` Rik van Riel
2014-07-31 6:22 ` [LKP] " Rik van Riel
2014-07-31 6:53 ` Aaron Lu
2014-07-31 6:53 ` [LKP] " Aaron Lu
2014-07-31 6:42 ` Rik van Riel
2014-07-31 6:42 ` [LKP] " Rik van Riel
2014-08-05 21:43 ` Rik van Riel
2014-08-05 21:43 ` [LKP] " Rik van Riel
2014-07-31 8:33 ` Peter Zijlstra
2014-07-31 8:33 ` [LKP] " Peter Zijlstra
2014-07-31 8:56 ` Aaron Lu
2014-07-31 8:56 ` [LKP] " Aaron Lu
2014-07-31 10:42 ` Peter Zijlstra
2014-07-31 10:42 ` [LKP] " Peter Zijlstra
2014-07-31 15:57 ` Peter Zijlstra
2014-07-31 15:57 ` [LKP] " Peter Zijlstra
2014-07-31 16:16 ` Jirka Hladky
2014-07-31 16:16 ` [LKP] " Jirka Hladky
2014-07-31 16:27 ` Peter Zijlstra
2014-07-31 16:27 ` [LKP] " Peter Zijlstra
2014-07-31 16:39 ` Jirka Hladky
2014-07-31 16:39 ` [LKP] " Jirka Hladky
2014-07-31 17:37 ` Peter Zijlstra
2014-07-31 17:37 ` [LKP] " Peter Zijlstra
2014-08-01 15:02 ` Peter Zijlstra
2014-08-01 15:02 ` [LKP] " Peter Zijlstra
2014-08-01 20:46 ` Davidlohr Bueso
2014-08-01 20:46 ` [LKP] " Davidlohr Bueso
2014-08-01 20:48 ` Davidlohr Bueso
2014-08-01 20:48 ` [LKP] " Davidlohr Bueso
2014-08-01 21:30 ` Jirka Hladky [this message]
2014-08-01 21:30 ` Jirka Hladky
2014-08-02 4:17 ` Rik van Riel
2014-08-02 4:17 ` [LKP] " Rik van Riel
2014-08-02 5:28 ` Jirka Hladky
2014-08-02 5:28 ` [LKP] " Jirka Hladky
2014-08-02 4:26 ` Peter Zijlstra
2014-08-02 4:26 ` [LKP] " Peter Zijlstra
2014-08-01 0:18 ` Davidlohr Bueso
2014-08-01 0:18 ` [LKP] " Davidlohr Bueso
2014-08-01 2:03 ` Aaron Lu
2014-08-01 2:03 ` [LKP] " Aaron Lu
2014-08-01 4:03 ` Davidlohr Bueso
2014-08-01 4:03 ` [LKP] " Davidlohr Bueso
2014-08-01 7:29 ` Peter Zijlstra
2014-08-01 7:29 ` [LKP] " Peter Zijlstra
2014-08-01 7:29 ` Peter Zijlstra
2014-08-01 7:29 ` [LKP] " Peter Zijlstra
2014-07-31 23:58 ` Yuyang Du
2014-07-31 23:58 ` [LKP] " Yuyang Du
2014-08-01 8:14 ` Fengguang Wu
2014-08-01 8:14 ` [LKP] " 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=53DC06FA.8030104@redhat.com \
--to=jhladky@redhat.com \
--cc=lkp@lists.01.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.