Re: [RFC] Simple NUMA scheduler patch

[Martin J. Bligh]

> it's a start. But I'm afraid a full solution will need much more code
> (which is one of the problems with my NUMA scheduler patch).

Right, but a sequence of smaller patches will be easier to get in.
I see this as a first step towards your larger patch ... if we can
do something simpler like Michael has, with enough view to your
later plans to make them merge together cleanly, I think we have
the best of both worlds ... Erich, what would it take to make this
a first stepping stone towards what you have? Or is it there already?

The fact that Michael's patch seems to have better performance (at
least for the very simple tests I've done) seems to reinforce the
"many small steps" approach in my mind - it's easier to debug and
analyse like that.
 
> The ideas behind your patch are:
> 2. Favor own node for stealing if any CPU on the own node is >25%
> more loaded. Otherwise steal from another CPU if that one is >100%
> more loaded.
> ...
> 2. is ok as it makes it harder to change the node. But again, you don't
> aim at equally balanced nodes. And: if the task gets away from the node
> on which it got its memory, it has no reason to ever come back to it.

I don't think we should aim too hard for exactly equal balancing,
it may well result in small peturbations causing task bouncing between
nodes. 

> For a final solution I believe that we will need targets like:
> (a) equally balance nodes
> (b) return tasks to the nodes where their memory is
> (c) make nodes "sticky" for tasks which have their memory on them,
> "repulsive" for other tasks.

I'd add:

(d) take into account the RSS when migrating tasks across nodes
    (ie stickiness is proportional to amount of RAM used on nodes)

> But for a first attempt to get the scheduler more NUMA aware all this
> might be just too much.

Agreed ;-)

M.