Re: [PATCH] sched: smart wake-affine
From: Mike Galbraith
Date: Fri Jul 05 2013 - 01:41:27 EST
On Fri, 2013年07月05日 at 12:33 +0800, Michael Wang wrote:
>
On 07/05/2013 12:08 PM, Mike Galbraith wrote:
>
[snip]
>
>>
>
>> Wow, I used to think such issue is very hard to be tracked by
>
>> benchmarks, is this regression stable?
>
>
>
> Yeah, seems to be. I was curious as to why you saw an improvement to
>
> hackbench, didn't seem there should be any, so though I'd try it on my
>
> little box on the way to a long weekend. The unexpected happened.
>
>
Oh, I think I failed to explain things clearly in comments...
>
>
It's not the patch who bring 15% benefit to hackbench, but the
>
wake-affine stuff itself.
>
>
In the prev-test, I removed the whole stuff and find that hackbench
>
dropped 15%, which means with wake-affine enabled, we will gain 15%
>
benefit (and that's actually the reason why we don't kill the stuff).
Ah.
>
And this idea is try to not harm that 15% benefit, and meanwhile regain
>
the pgbench lost performance, thus, apply this patch to mainline won't
>
improve hackbench performance, but improve pgbench performance.
>
>
But this regression is really unexpected... I could hardly believe it's
>
just caused by cache issue now, since the number is not small (10% at
>
most?).
>
>
Have you tried to use more loops and groups? will that show even bigger
>
regressions?
Nope, less on either side.
hackbench -g 100 -l 1000
avg
3.10.0-regress 21.895 21.564 21.777 21.958 22.093 21.857 1.000
3.10.0-regressx 22.844 23.268 23.056 23.231 22.375 22.954 1.050
hackbench -g 1 -l 100000
avg
3.10.0-regress 29.913 29.711 30.395 30.213 30.236 30.093 1.000
3.10.0-regressx 30.392 31.003 30.728 31.008 30.389 30.704 1.020
>
BTW, is this the results of 10 group and 40 sockets == 400 tasks?
Yeah, stock.
Off to do some body/mind tuning. Bavarian mushrooms don't hide as well
as memory access thingies.. and I can still out run 'em.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/