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

From: Andi Kleen <>
Date: 2005-07-16 08:56:35
On Fri, Jul 15, 2005 at 03:49:33PM -0700, Christoph Lameter wrote:
> On Sat, 16 Jul 2005, Andi Kleen wrote:
> > > 1. Updating the memory policy is something that can be useful in other 
> > >    settings as well so it need to be separate. The patch we are discussing
> > 
> > Not for external processes except in the narrow special case
> > of migrating everything. External processes shouldn' t
> > know about virtual addresses of other people.
> Updating the memory policy is also useful if memory on one node gets 
> short and you want to redirct allocations to a node that has memory free. 

If you use MEMBIND just specify all the nodes upfront and it'll
do the normal fallback in them. 

If you use PREFERED it'll do that automatically anyways.

> A batch scheduler may anticipate memory shortages and redirect memory 
> allocations in order to avoid page migration.

I think that jobs more belongs to the kernel. After all we don't
want to move half of our VM into your proprietary scheduler.

> I'd rather have that logic in userspace rather than fix up page_migrate 
> again and again and again. Automatic recalculation of memory policies is 
> likely an unexpected side effect of the existing page migration code. 

Only if you migrate again and again.

> Policies should only change with explicit instructions from user space and 
> not as a side effect of page migration.

Well, page migration would be a "explicit instruction from user space" 

> And curiously with the old page migration code: The only way to change the 
> a memory policy is by page migration and this is automatically behind your 
> back.

mbind can change policy at any time. Just only for the local
process, as that is the the only one who has enough information
to really do this.

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 18:56:51 2005

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