Re: NUMA policy interface

Andi Kleen
2005-08-04T21:14:45Z

> 1. BIND policy implemented in a way that fills up nodes from the lowest
> to the higest instead of allocating memory on the local node.

Hmm, there was a patch from PJ for that at some point. Not sure why it
was not merged. iirc the first implementation was too complex, but
there was a second reasonable one.

>
> 2. No separation between sys_ and do_ functions. Therefore difficult
> to use from kernel context.

set_fs(KERNEL_DS)
Some policies can be even set without that.

There are already kernel users BTW that prove you wrong.

> 3. Functions have weird side effect (f.e. get_nodes updating
> and using cpuset policies). Code is therefore difficult
> to maintain.

Agreed that should be cleaned up.

> 4. Uses bitmaps instead of nodemask_t.

Should be easy to fix if someone is motivated. When I wrote the code
nodemask_t didn't exist yet, and when it was merged it wasn't
converted over. Not a big deal.

>
> 5. No means to figure out where the memory was allocated although
> mempoliy.c implements scans over ptes that would allow that
> determination.

You lost me here.

>
> 6. Needs hook into page migration layer to move pages to either conform
> to policy or to move them menually.

Does it really? So far my feedback from all users I talked to is that they only
use a small subset of the functionality, even what is there is too complex.
Nobody with a real app so far has asked me for page migration.

There was one implementation of simple page migration in Steve L.'s patches,
but that was just because it was too hard to handle one corner case
otherwise.

> The long term impact of this missing functionality is already showing
> in the numbers of workarounds that I have seen at a various sites,

Examples?

-Andi