Re: [patch[ Simple Topology API

[Matthew Dobson <colpatch@us.ibm.com>]

Andi Kleen wrote:
> Andrew Morton <akpm@zip.com.au> writes:
>>AFAIK, the interested parties with this and the memory binding API are
>>ia32-NUMA, ia64, PPC, some MIPS and x86-64-soon.  It would be helpful
>>if the owners of those platforms could review this work and say "yes,
>>this is something we can use and build upon".  Have they done that?
> 
> Comment from the x86-64 side: 
> 
> Current x86-64 NUMA essentially has no 'nodes', just each CPU has
> local memory that is slightly faster than remote memory. This means
> the node number would be always identical to the CPU number. As long
> as the API provides it's ok for me. Just the node concept will not be
> very useful on that platform. memblk will also be identity mapped to
> node/cpu.
> 
> Some way to tell user space about memory affinity seems to be useful,
> but...
That shouldn't be a problem at all.  Since each architecture is responsible for 
defining the 5 main topology functions, you could do this:

#define _cpu_to_node(cpu)	(cpu)
#define _memblk_to_node(memblk)	(memblk)
#define _node_to_node(node)	(node)
#define _node_to_cpu(node)	(node)
#define _node_to_memblk(node)	(node)

> General comment:
> 
> I don't see what the application should do with the memblk concept
> currently. Just knowing about it doesn't seem too useful. 
> Surely it needs some way to allocate memory in a specific memblk to be useful?
> Also doesn't it need to know how much memory is available in each memblk?
> (otherwise I don't see how it could do any useful partitioning)
For that, you need to look at the Memory Binding API that I sent out moments 
after this patch...  It builds on top of this infrastructure to allow binding 
processes to individual memory blocks or groups of memory blocks.

Cheers!

-Matt

> 
> -Andi
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>