Re: [tip:sched/numa] sched/numa: Introduce sys_numa_{t,m}bind()

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

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.