-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/31/2014 01:04 AM, Aaron Lu wrote:
+++ b/kernel/sched/fair.c @@ -924,10 +924,12 @@ static inline
unsigned long group_faults_cpu(struct numa_group *group, int
nid)
/* * These return the fraction of accesses done by a
On 08/02/2014 06:17 AM, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/01/2014 05:30 PM, Jirka Hladky wrote:
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_
On Fri, Aug 01, 2014 at 11:30:34PM +0200, Jirka Hladky wrote:
> I see the regression only on this box. It has 4 "Ivy Bridge-EX" Xeon E7-4890
> v2 CPUs.
That's the exact CPU I've got in the 4 node machine I did the tests on.
pgpSRWYqkSh2L.pgp
Description: PGP signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/01/2014 05:30 PM, Jirka Hladky wrote:
> 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_Br
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
On Fri, 2014-08-01 at 13:46 -0700, Davidlohr Bueso wrote:
> So both these are pretty similar, however, when reverting, on avg we
> increase the amount of bops a mere ~4%:
>
> tip/master + reverted:
Just to be clear, this is reverting a43455a1d57.
--
To unsubscribe from this list: send the line "
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.
On Thu, Jul 31, 2014 at 07:37:05PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 31, 2014 at 06:39:05PM +0200, Jirka Hladky wrote:
> > I'm doing 3 iterations (3 runs) to get some statistics. To speed up the test
> > significantly please do the run with 20 warehouses only
> > (or in general with #wareh
On Fri, Aug 01, 2014 at 09:29:11AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 01, 2014 at 10:03:30AM +0800, Aaron Lu wrote:
> > > > > ebe06187bf2aec1 a43455a1d572daf7b730fe12e
> > > > > --- -
> > > > > 94500 ~ 3%+115.6% 203711 ~ 6%
> > > > >
On Fri, Aug 01, 2014 at 09:29:11AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 01, 2014 at 10:03:30AM +0800, Aaron Lu wrote:
> > > > > ebe06187bf2aec1 a43455a1d572daf7b730fe12e
> > > > > --- -
> > > > > 94500 ~ 3%+115.6% 203711 ~ 6%
> > > > >
On Thu, Jul 31, 2014 at 09:03:22PM -0700, Davidlohr Bueso wrote:
>
> Instead of removing info, why not document what each piece of data
> represents. Or add headers to the table. etc.
Yes headers are good, knowing exactly what a number is often removes a
lot of confusion ;-)
pgpKZNok1PSKp.pgp
D
On Fri, Aug 01, 2014 at 10:03:30AM +0800, Aaron Lu wrote:
> > > > ebe06187bf2aec1 a43455a1d572daf7b730fe12e
> > > > --- -
> > > > 94500 ~ 3%+115.6% 203711 ~ 6%
> > > > ivb42/hackbench/50%-threads-pipe
> > > > 67745 ~ 4% +64.1% 11
On Fri, 2014-08-01 at 10:03 +0800, Aaron Lu 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 wrote:
> > >
> > > > FYI, we noticed the below changes on
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 wrote:
> >
> > > FYI, we noticed the below changes on
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/next
On Thu, 2014-07-31 at 12:42 +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 wrote:
> >
> > > FYI, we noticed the below changes on
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
On Thu, Jul 31, 2014 at 06:39:05PM +0200, Jirka Hladky wrote:
> I'm doing 3 iterations (3 runs) to get some statistics. To speed up the test
> significantly please do the run with 20 warehouses only
> (or in general with #warehouses == number of nodes * number of PHYSICAL
> cores)
Yeah, went and
On 07/31/2014 06:27 PM, Peter Zijlstra wrote:
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 Ju
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 w
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 wrote:
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/li
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 wrote:
> >
> > > FYI, we noticed the below changes on
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/next
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 wrote:
>
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > commit a43455a1d572daf7b730fe12eb747d1e17411365 ("s
On Thu, Jul 31, 2014 at 10:33:30AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 30, 2014 at 10:14:25AM +0800, Aaron Lu wrote:
> > 118881 ~ 0%+1.2%120325 ~ 0% ivb42/hackbench/50%-threads-pipe
>
> What kind of IVB is that EP or EX (or rather, how many sockets)? Also
> what arguments to
On Wed, Jul 30, 2014 at 10:14:25AM +0800, Aaron Lu wrote:
> 118881 ~ 0%+1.2%120325 ~ 0% ivb42/hackbench/50%-threads-pipe
What kind of IVB is that EP or EX (or rather, how many sockets)? Also
what arguments to hackbench do you use?
pgpaZ5R1fdmdc.pgp
Description: PGP signature
On Thu, Jul 31, 2014 at 02:22:55AM -0400, Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/31/2014 01:04 AM, Aaron Lu wrote:
> > On Wed, Jul 30, 2014 at 10:25:03AM -0400, Rik van Riel wrote:
> >> On 07/29/2014 10:14 PM, Aaron Lu wrote:
> >>> On Tue, Jul 29, 2014 at 0
On Thu, 31 Jul 2014 13:04:54 +0800
Aaron Lu wrote:
> On Wed, Jul 30, 2014 at 10:25:03AM -0400, Rik van Riel wrote:
> > On 07/29/2014 10:14 PM, Aaron Lu wrote:
> > >> +#define NUMA_SCALE 1024
> > >> +#define NUMA_MOVE_THRESH (5 * NUMA_SCALE / 100)
> >
> > It would be good to see if changing NUMA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/31/2014 01:04 AM, Aaron Lu wrote:
> On Wed, Jul 30, 2014 at 10:25:03AM -0400, Rik van Riel wrote:
>> On 07/29/2014 10:14 PM, Aaron Lu wrote:
>>> On Tue, Jul 29, 2014 at 04:04:37PM -0400, Rik van Riel wrote:
On Tue, 29 Jul 2014 10:17:12 +0200
On Wed, Jul 30, 2014 at 10:25:03AM -0400, Rik van Riel wrote:
> On 07/29/2014 10:14 PM, Aaron Lu wrote:
> > On Tue, Jul 29, 2014 at 04:04:37PM -0400, Rik van Riel wrote:
> >> On Tue, 29 Jul 2014 10:17:12 +0200
> >> Peter Zijlstra wrote:
> >>
> +#define NUMA_SCALE 1000
> +#define NUMA_MOV
On 07/29/2014 10:14 PM, Aaron Lu wrote:
> On Tue, Jul 29, 2014 at 04:04:37PM -0400, Rik van Riel wrote:
>> On Tue, 29 Jul 2014 10:17:12 +0200
>> Peter Zijlstra wrote:
>>
+#define NUMA_SCALE 1000
+#define NUMA_MOVE_THRESH 50
>>>
>>> Please make that 1024, there's no reason not to use powe
On Tue, Jul 29, 2014 at 04:04:37PM -0400, Rik van Riel wrote:
> On Tue, 29 Jul 2014 10:17:12 +0200
> Peter Zijlstra wrote:
>
> > > +#define NUMA_SCALE 1000
> > > +#define NUMA_MOVE_THRESH 50
> >
> > Please make that 1024, there's no reason not to use power of two here.
> > This base 10 factor th
On Tue, 29 Jul 2014 10:17:12 +0200
Peter Zijlstra wrote:
> > +#define NUMA_SCALE 1000
> > +#define NUMA_MOVE_THRESH 50
>
> Please make that 1024, there's no reason not to use power of two here.
> This base 10 factor thing annoyed me no end already, its time for it to
> die.
That's easy enough.
On Tue, Jul 29, 2014 at 02:39:40AM -0400, Rik van Riel wrote:
> Subject: sched,numa: prevent task moves with marginal benefit
>
> Commit a43455a1d57 makes task_numa_migrate() always check the
> preferred node for task placement. This is causing a performance
> regression with hackbench, as well as
On Tue, 29 Jul 2014 13:24:05 +0800
Aaron Lu 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")
>
> eb
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
--- ---
33 matches
Mail list logo
