Re: [NUMA] Display and modify the memory policy of a process through /proc/<pid>/numa_policy

From: Andi Kleen <>
Date: 2005-07-16 12:01:41
> One always needs control over what is migrated. Ideally one would be able 
> to specify that only the vma containing the huge amount of sparsely 
> accessed data is to be migrated if memory becomes tight but the process 
> continues to run on the same node. The stack and text segments and 
> libraries should stay on the node.

There is no way to do sane locking from user space 
for such external manipulation of arbitary mappings.  You need
to do it in the kernel.

BTW all your talking about VMAs is useless here anyways because
NUMA policies don't necessarily match VMAs and neither does
allocated memory. 

> Are you willing to allow us to control memory placement? Or will it be 

> automatically? If automatically then maybe you need to get rid of libnuma 
> and numactl and put it all in the scheduler. Otherwise please full control 
> and not some half-way measures.

Without my NUMA policy code you wouldn't have any usable NUMA policy today,
But my goal is definitely to keep the kernel interfaces for this
clean. And what you're proposing is *not* clean. 

I think the per VMA approach is fundamentally wrong because
virtual addresses are nothing an external user can safely
access.  Doing it on higher level objects allows better interfaces
and better locking, and as far as I can see process/shm segment/file
are the only useful objects for this. 

It should basically work like swapping without the need to SIGSTOP
the target.

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Fri Jul 15 22:01:51 2005

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:40 EST