On Fri, 15 Jul 2005, Andi Kleen wrote:

So for what does that batch monstrosity need to know 
about the VMAs? 

It needs to know where the memory of a process is. Thus 
/proc/<pid>/numa_maps.

I don't believe any admin will mess with virtual addresses.

No but they will mess with vma's which are only identifiable by the 
starting virtual address.
 

But for "uncooperative" programs working on bigger objects
like threads/files/shm areas/processes makes much more sense. And gives
much cleaner interfaces too.

Look at the existing patches and you see a huge complexity and heuristics 
because the kernel guesses which vma's to migrate. If the vma are 
exposed to the batch scheduler / admin then things become much easier to 
implement and the batch scheduler / admin has finer grained control.

Now I can see some people being interested in more fine grained
policy, but the only sane way to do that is to change the source
code and use libnuma.

Can libnuma change the memory policy and move pages of existing processes?
 

Basically to mess with finegrained virtual addresses you need code access,
and when you have that you can as well do it well and add 
libnuma and recompile.

libnuma is pretty heavy and AFAIK does not have the functionality that is 
required here.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>