Re: Idle power fix regresses ebizzy performance (was 3.12-stable backport of NUMA balancing patches)

[Mel Gorman <mgorman@suse.de>]

On Fri, Jan 10, 2014 at 01:04:55AM -0500, Len Brown wrote:
> Hi Mel,
> 
> I downloaded ebizzy and ran on an 80-thread WSM-EX.

Default parameters? If so, the default is 2xNR_CPUs. My initial tests only
ran up to NR_CPUs but I was seeing regressions throughout so I doubt it
levelled out for higher numbers of clients.

I used mmtests to run ebizzy based on the
configs/config-global-dhp__pagealloc-performance config file with the
following relevant lines changed just for the bisection itself

export MMTESTS="ebizzy"
export EBIZZY_MAX_THREADS=5
export EBIZZY_DURATION=20
export EBIZZY_ITERATIONS=3

Even though the test ran up to 5 threads, I only was using the result
for 4 threads for the bisection.

> But I got quite different number than you, so I'm wondering if there is
> something
> special I need to get the same results you see.  I generally see scores
> around 6900 - 7000.
> my reference kernel is built on top of
> b0031f227e47919797dc0e1c1990f3ef151ff0cc
> which is upstream on 12/17, which is when i wrote that patch -- if it
> matters.
> 
> But worse, I don't see any difference in ebizzy performance with/without
> the CLFLUSH patch.
> 
> Please let me know what I can do to reproduce the results you see.
> 

You could try running within mmtests and see what falls out? I don't think
I am doing anything weird in there but it wouldn't be the first time there
was a mistake in testing methodology that led to inconsistent results
between testers.

git clone https://github.com/gormanm/mmtests
cd mmtests
vi configs/config-global-dhp__pagealloc-performance
# edit file to set the lines above to match my bisection
./run-mmtests.sh --no-monitor --config configs/config-global-dhp__pagealloc-performance baseline
# boot new kernel
./run-mmtests.sh --no-monitor --config configs/config-global-dhp__pagealloc-performance patched
cd work/log
../../compare-kernels.sh

Of course, we could also be differing on kernel config in some relevant
way or it might be some other unfortunate timing issue.

> Also, can you try this attached incremental patch to see if it helps?

I'll fire it up after pushing send on this mail.

Thanks

-- 
Mel Gorman
SUSE Labs