| 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: Mon, 03 Jun 2013 14:31:39 +0800 From: Michael Wang <wangyun@...ux.vnet.ibm.com> To: Mike Galbraith <efault@....de> CC: LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.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: [RFC PATCH] sched: smart wake-affine On 06/03/2013 02:05 PM, Mike Galbraith wrote: > On Mon, 2013-06-03 at 13:50 +0800, Michael Wang wrote: >> On 06/03/2013 01:22 PM, Mike Galbraith wrote: >> [snip] >>>> >>>> I agree that this idea, in other work, 'stop wake-affine when current is >>>> busy with wakeup' may miss the chance to bring benefit, although I could >>>> not find such workload, but I can't do promise... >>> >>> Someday we'll find the perfect balance... likely the day before the sun >>> turns into a red giant and melts the earth. >> >> Won't take so long ;-) >> >> I would like to stop the regression on pgbench firstly, as PeterZ >> mentioned, if someone reported other regressions, we will know what is >> missing, if fix is possible, we fix it, if cost is too high, then I say >> we ignore the illegal income, after all, we could not benefit one in the >> cost of sacrifice others... >> >> I'd like to fix the problem ASAP, it's really a big, urgent problem on >> my point of view, but doesn't win enough attentions as I thought it will... > > I fully agree that it's a problem, but not that it's a regression. I won't disagree, it's just the view point, I used to compare the whole thing with/without wake-affine stuff, and I found it damage pgbench to benefit hackbench, furthermore, that was in mainline by default... The > "we became too buddy-centric" problem has existed for a long time, it's > just that pgbench in 1:N mode shows us how much that pull pull pull can > cost us in scalability. Agree, that was something we missed when we are so happily figure out the good-side of pull... > > A much more interesting pgbench test (imho) would be with one server per > socket. May be configure the database could achieve that, sounds like a better deployment to me ;-) 1 server (mother of all work) driving a multi-socket sized load > is just silly, can't possibly scale, so it's important that improving > 1:N pgbench (we can, and need to) doesn't harm sane loads. I guess the pgbench behaviour is badly depends on the database configuration on box, I think there are still many interesting points we could dig :) Anyway, I still prefer to do it step by step, if we do not fix the issue we already found, then the deeper research will based on an forked unreal world... Regards, Michael Wang > > -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/ > -- 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