Ingo Molnar wrote:
> On 18 Jun 2002, Michael Hohnbaum wrote:
>>[...] I would suggest an additional argument be added
>>which would indicate the resource that the process is to be
>>affined to.  That way this interface could be used for binding
>>processes to cpus, memory nodes, perhaps NUMA nodes, and, 
>>as discussed recently in another thread, other processes.
>>Personally, I see NUMA nodes as an overkill, if a process
>>can be bound to cpus and memory nodes.
> 
> 
> are you sure we want one generic, process-based affinity interface?
> 
> i think the affinity to certain memory regions might need to be more
> finegrained than this. Eg. it could be useful to define a per-file
> (per-inode) 'backing store memory node' that the file is affine to. This
> will eg. cause the pagecache to be allocated in the memory node.
> Process-based affinity does not describe this in a natural way. Another
> example, memory maps: we might want to have a certain memory map (vma)  
> allocated in a given memory node, independently of where the process that
> is faulting a given pages resides.
> 
> and it might certainly make sense to have some sort of 'default memory
> affinity' for a process as well, but this should be a different syscall -
> it really does a much different thing than CPU affinity. The CPU resource
> is 'used' only temporarily with little footprint, while memory usage is
> often for a very long timespan, and the affinity strategies differ
> greatly. Also, memory as a resource is much more complex than CPU, eg. it
> must handle things like over-allocation, fallback to 'nearby' nodes if a
> node is full, etc.

I've attatched copies of the patch that Michael referred to in his email so you 
  can see where we're going with this.  I think that we have (at least the 
beginnings) of what you've described.  The patch allows processes to bind to 
specific CPU's (via bitmask) and/or specific memory blocks.  You can set these 
up to complement each other, or to something completely arbitrary (for 
debugging purposes, etc).  It also includes the beginnings of very simple 
topology info with some simple arch-independent calls (cpu_to_node, 
node_to_cpu, node_to_memblk, etc.)  Of course these do require some lower level 
hooks for each architecture that wants to use them, but they should be simple 
calls.  I've been sidetracked on other things for about a month, but I plan on 
getting back to this patch ASAP (this week), and porting it forward to the 
latest version.  It is currently only up to 2.5.14.

If anyone has any suggestions for other features, changes, comments, flames, 
ANYTHING, please let me know.


> so i'd suggest to actually create a good memory-affinity syscall interface
> instead of trying to generalize it into the simple, robust, finite
> CPU-affinity syscalls.
See above ;)


-Matt

> 
> 	Ingo
> 
> -
> 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/
>