linux-kernel - Re: [PATCH] sched: smart wake-affine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1373002865.8318.11.camel@marge.simpson.net>
Date:	Fri, 05 Jul 2013 07:41:05 +0200
From:	Mike Galbraith <efault@....de>
To:	Michael Wang <wangyun@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>, Alex Shi <alex.shi@...el.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Paul Turner <pjt@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>,
	Ram Pai <linuxram@...ibm.com>
Subject: Re: [PATCH] sched: smart wake-affine

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/