Re: 2.4.19pre1aa1

["Martin J. Bligh" <Martin.Bligh@us.ibm.com>]

> it's not more complex than the current way, it's just different and it's
> not strict, but it's the best one for allocations that doesn't "prefer"
> memory from a certain node, but OTOH we don't have an API to define
> 'waek' or 'strict' allocation bheaviour so the default would better be
> the 'strict' one like in oldnuma. Infact in the future we may want to
> have also a way to define a "very strict" allocation, that means it
> won't fallback into the other nodes at all, even if there's plenty of
> memory free on them.  An API needs to be built with some bitflag
> specifying the "strength" of the numa affinity required. Your layout
> provides the 'weakest' approch, that is perfectly fine for some kind of
> non-numa-aware allocations, just like "very strict" will be necessary
> for the relocation bindings (if we cannot relocate in the right node
> there's no point to relocate in another node, let's ingore complex
> topologies for now :).

Actually, we (IBM) do have a simple API to do this that Matt Dobson 
has been working on that's nearing readiness (& publication). I've 
been coding up a patch to _alloc_pages today that has both a strict 
and non-strict binding in it. It first goes through your "preferred" set of 
nodes (defined on a per-process basis), then again looking for any 
node that you've not strictly banned from the list - I hope that's 
sufficient for what you're discussing? I'll try to publish my part tommorow, 
definitely this week - it'll be easy to see how it works in conjunction with 
the API, though the rest of the API might be a little longer before arrival ....

Martin.