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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20120319143002.GQ24602@redhat.com>
Date:	Mon, 19 Mar 2012 15:30:02 +0100
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	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

On Mon, Mar 19, 2012 at 04:06:43PM +0200, Avi Kivity wrote:
> I agree with Peter on this, but perhaps it's because my app will take
> all of 15 minutes to patch.  Up front knowledge is better than the
> kernel discovering it on its own.

I agree for qemu those soft bindings are fine.

But how you compute the statistical data is most difficult part, how
you collect them not so important after all.

The scheduler code Peter said is "that's not going to ever happen"
took several weeks of benchmarking and several rewrites to actual
materialize and be super happy about the core algorithm. If it's
simplified and just loops over the CPUs is because when you do
research and invent you can't waste time on actual implementation
details that just slow you down on the next rewrite of the algorithm
as you have to try again. So if my algorithms (abeit in a simplified
form compared to a real full implementation) works better, not having
the background scanning won't help Peter at all and you'll still be
better off with AutoNUMA.

When you focus only on the cost of collecting the information and no
actual discussion was spent yet on how to compute or react to it,
something's wrong... as that's the really interesting part of the code.

The fact the autonuma_balance() is simplified implementation is still
perfectly ok right now, as that's totally hidden kernel internal
thing, not even affecting kABI. Can be improved any time. Plus it's
not like it will backfire, it just won't be running as good as a full
more complex implementation that takes into account all the
runqueues. And implementating that won't be easy at all, there are
simpler things that are more urgent at this point.
--
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/