lkml.org 
[lkml]   [2012]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:sched/numa] sched/numa: Introduce sys_numa_{t,m}bind()

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

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

These APIs also match what user-space numa daemons started doing
already.

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

The grouping is also a natural extension to task and memory
affinities and groups in general.

It also allows us to turn auto-migration off by default, which
is a plus in my book. Without enough numbers I'm not convinced
that we really *want* auto-discovery turned on all the time, for
all workloads. The thing is, in practice most workloads that
matter are short-run and even trivial forms of CPU migration
doesnt ever happen for bursts of activity. We place them and
that's it.

Managed runtimes on the other hand can be expected to know about
and manage their locality - they do it anyway, by running guest
scheduler(s). So this patch-set gives them the ability to
express locality in a simple way, without the host kernel
scanning actively.

We can auto-scan on top of this, if the numbers support it, but
in the simple case where both the guest and the host is smart
then simply expressing locality and telling each other is vastly
superior to any scanning method.

Thanks,

Ingo


\
 
 \ /
  Last update: 2012-05-19 13:41    [from the cache]
©2003-2011 Jasper Spaans