> 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 toexpress such relations. That said.. I never said we shouldn't/couldn'thelp 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 dataseparation in your application, so telling the kernel about it isn't toomuch bother, right?

The thing is, I've been traumatized by too much exposure to theauto-parallelization crazies. I've never seen auto parallelization worthusing, despite lots of presumably smart people wanting to make ithappen.

> > 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 vnumadoesn't have the scambling issue outlined earlier since the guest kernelwould 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 withper-cpu memory, since you explicitly tell it where it belongs.