linux-kernel - Re: [RFC][PATCH 00/26] sched/numa

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 19 Mar 2012 22:34:17 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Andrea Arcangeli <aarcange@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Avi Kivity <avi@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, Paul Turner <pjt@...gle.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Mike Galbraith <efault@....de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Dan Smith <danms@...ibm.com>,
	Bharata B Rao <bharata.rao@...il.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC][PATCH 00/26] sched/numa


* Christoph Lameter <cl@...ux.com> wrote:

> On Mon, 19 Mar 2012, Ingo Molnar wrote:
> 
> > > I wonder how we can verify that the automatic migration 
> > > schemes are a real benefit to the application? We have a 
> > > history of developing a kernel that decreases in 
> > > performance as development proceeds. How can we make sure 
> > > that these schemes are actually beneficial overall for all 
> > > loads and do not cause regressions elsewhere? [...]
> >
> > The usual way?
> 
> Which is merge after a couple of benchmarks and then deal with 
> the regressions for a couple of years?
>
> [...]

No, and I gave you my answer:

> Obviously any such scheme must be a win in general for it to be 
> default on. We don't have the numbers to justify that - and I'm 
> sceptical whether it will be possible, but I'm willing to be 
> surprised.
> 
> I'm especially sceptical since most mainstream NUMA systems tend 
> to have a low NUMA factor. Thus the actual cost of being NUMA is 
> pretty low.
> 
> That having said PeterZ's numbers showed some pretty good 
> improvement for the streams workload:
> 
>  before: 512.8M
>   after: 615.7M
> 
> i.e. a +20% improvement on a not very heavily NUMA box.
> 
> That kind of raw speedup of a CPU execution workload like 
> streams is definitely not something to ignore out of hand. *IF* 
> there is a good automatism that can activate it for the apps 
> that are very likely to benefit from it then we can possibly do 
> it.
> 
> But a lot more measurements have to be done, and I'd be also 
> very interested in the areas that regress.
> 
> Otherwise, if no robust automation is possible, it will have to 
> be opt-in, on a per app basis, with both programmatic and 
> sysadmin knobs available. (who will hopefully make use if it...)
> 
> That's the best we can do I think.

Thanks,

	Ingo
--
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/