linux-kernel - Re: [tip:sched/numa] sched/numa: Introduce sys_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: <1337357128.573.88.camel@twins>
Date:	Fri, 18 May 2012 18:05:28 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Rik van Riel <riel@...hat.com>
Cc:	mingo@...nel.org, hpa@...or.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, pjt@...gle.com, cl@...ux.com,
	bharata.rao@...il.com, akpm@...ux-foundation.org,
	Lee.Schermerhorn@...com, aarcange@...hat.com, danms@...ibm.com,
	suresh.b.siddha@...el.com, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/numa] sched/numa: Introduce sys_numa_{t,m}bind()

On Fri, 2012-05-18 at 11:48 -0400, Rik van Riel wrote:

> Whether we like it or not, managed runtimes are here,
> and people are using them in droves.
> 
> I believe that the kernel should be able to handle
> NUMA placement for such uses.

Possibly, but it would also help if runtimes grew the capability to
express such relations. That said..  I never said we shouldn't/couldn't
help them eventually.

> > I still have serious concerns about his approach; it very much assumes
> > there's a temporal page<->thread relation to exploit. This might not at
> > all be true for some programs (including JVM) that have hardly any data
> > separation and just point chase their way around the entire object set.
> 
> Neither his approach or your approach will be able to
> help these workloads. I do not see how that should be
> counted against Andrea's approach, though, since it
> does seem to be useful for sane workloads.

Well, if you have a sane workload you often already have strong data
separation in your application, so telling the kernel about it isn't too
much bother, right?

The thing is, I've been traumatized by too much exposure to the
auto-parallelization crazies. I've never seen auto parallelization worth
using, despite lots of presumably smart people wanting to make it
happen.

> > I very much believe in doing the simple thing first, and this is that,
> 
> Leave out your syscalls (which might not be useful for
> managed runtimes), and you actually have the simple
> thing :)

Right, but the virt people could actually trivially use those, and vnuma
doesn't have the scambling issue outlined earlier since the guest kernel
would also try to keep home-node affinity.

Avi already said patching kvm would be like 5 minutes work.

It also absolutely avoids the false sharing issue otherwise present with
per-cpu memory, since you explicitly tell it where it belongs.

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