Re: [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local

[Peter Zijlstra <peterz@infradead.org>]

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

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 #warehouses ==  number of nodes * number of PHYSICAL
> > cores)
> 
> Yeah, went and did that for my 4 node machine, its got a ton more cores, but I
> matches the warehouses to it:
> 
> -a43455a1d57	tip/master
> 
> 979996.47	1144715.44
> 876146		1098499.07
> 1058974.18	1019499.38
> 1055951.59	1139405.22
> 970504.01	1099659.09
> 
> 988314.45	1100355.64	(avg)
> 75059.546179565	50085.7473975167(stdev)
> 
> So for 5 runs, tip/master (which includes the offending patch) wins hands down.
> 
> Each run is 2 minutes.

Because Rik asked for a43455a1d57^1 numbers:

546423.08
546558.63
545990.01
546015.98

some a43455a1d57 numbers:

538652.93
544333.57
542684.77

same setup and everything. So clearly the patches after that made 'some'
difference indeed, seeing how tip/master is almost twice that.

So the reason I didn't so a43455a1d57^1 vs a43455a1d57 is because we already
fingered a commit, after that what you test is the revert of that commit,
because revert is what you typically end up doing if a commit is fail.

But on the state of tip/master, taking that commit out is a net negative for
everything I've tested.

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