Re: [PATCH/RFC 3/5] Mem Policy: MPOL_PREFERRED fixups for "local allocation"

[Christoph Lameter <clameter@sgi.com>]

On Tue, 11 Sep 2007, Lee Schermerhorn wrote:

> > >  	case MPOL_PREFERRED:
> > > -		/* or use current node instead of memory_map? */
> > > +		/*
> > > +		 * for "local policy", return allowed memories
> > > +		 */
> > >  		if (p->v.preferred_node < 0)
> > > -			*nodes = node_states[N_HIGH_MEMORY];
> > > +			*nodes = cpuset_current_mems_allowed;
> > 
> > Is this change intentional? It looks like something that belongs as part
> > of the the memoryless patch set.
> > 
> 
> Absolutely intentional.  The use of 'node_states[N_HIGH_MEMORY]' was
> added by the memoryless nodes patches.  Formerly, this was
> 'node_online_map'.  However, even this results in misleading info for
> tasks running in a cpuset.  

Sort of. This just means that the policy does not restrict the valid 
nodes. The cpuset does. I think this is okay but we may be confusing users 
as to which mechanism performs the restriction.
 
> It's a fine, point, but I think this is "more correct" that the existing
> code.  I'm hoping that this change, with a corresponding man page update
> will head off some head scratching and support calls down the road.

How does this sync with the nodemasks used by other policies? So far we 
are using a sort of cpuset agnostic nodeset and limit it when it is 
applied. I think the integration between cpuset and memory policies could 
use some work and this is certainly something valid to do. Is there any 
way to describe that and have output that clarifies that distinction and 
helps the user figure out what is going on?


--
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:"dont@kvack.org"> email@kvack.org </a>