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
| ||
|
Date: Fri, 05 Jul 2013 06:08:38 +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 10:47 +0800, Michael Wang wrote: > On 07/04/2013 06:33 PM, Mike Galbraith wrote: > [snip] > >> Well, seems like we still have many follow-up research works after fix > >> the issue ;-) > > > > Yeah. Like how to how to exterminate the plus sign, they munch cache > > lines, and have a general tendency to negatively impact benchmarks. > > > > Q6600 box, hackbench -l 1000 > > avg > > 3.10.0-regress 2.293 2.297 2.313 2.291 2.295 2.297 1.000 > > 3.10.0-regressx 2.560 2.524 2.427 2.599 2.602 2.542 1.106 > > 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. > > pahole said... > > > > marge:/usr/local/src/kernel/linux-3.x.git # tail virgin > > long unsigned int timer_slack_ns; /* 1512 8 */ > > long unsigned int default_timer_slack_ns; /* 1520 8 */ > > atomic_t ptrace_bp_refcnt; /* 1528 4 */ > > > > /* size: 1536, cachelines: 24, members: 125 */ > > /* sum members: 1509, holes: 6, sum holes: 23 */ > > /* bit holes: 1, sum bit holes: 26 bits */ > > /* padding: 4 */ > > /* paddings: 1, sum paddings: 4 */ > > }; > > > > marge:/usr/local/src/kernel/linux-3.x.git # tail michael > > long unsigned int default_timer_slack_ns; /* 1552 8 */ > > atomic_t ptrace_bp_refcnt; /* 1560 4 */ > > > > /* size: 1568, cachelines: 25, members: 128 */ > > /* sum members: 1533, holes: 8, sum holes: 31 */ > > /* bit holes: 1, sum bit holes: 26 bits */ > > /* padding: 4 */ > > /* paddings: 1, sum paddings: 4 */ > > /* last cacheline: 32 bytes */ > > }; > > > > ..but plugging holes, didn't help, moving this/that around neither, nor > > did letting pahole go wild to get the line back. It's plus signs I tell > > ya, the evil things must die ;-) > > Hmm...so the new members kicked some tail members to a new line...or may > be totally different when compiler take part in... > > It's really hard to estimate the influence, especially when the > task_struct is still keep changing... Yeah, could be memory layout crud that disappears with the next pull/build. Wouldn't be the first time. -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/
Powered by blists - more mailing lists