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

[Lee Schermerhorn <Lee.Schermerhorn@hp.com>]

On Wed, 2007-09-12 at 15:06 -0700, Christoph Lameter wrote:
> On Thu, 30 Aug 2007, Lee Schermerhorn wrote:
> 
> > 1)  [do_]get_mempolicy() calls the now renamed get_policy_nodemask()
> >     to fetch the nodemask associated with a policy.  Currently,
> >     get_policy_nodemask() returns the set of nodes with memory, when
> >     the policy 'mode' is 'PREFERRED, and the preferred_node is < 0.
> >     Return the set of allowed nodes instead.  This will already have
> >     been masked to include only nodes with memory.
> 
> Ok.
>  
> > 2)  When a task is moved into a [new] cpuset, mpol_rebind_policy() is
> >     called to adjust any task and vma policy nodes to be valid in the
> >     new cpuset.  However, when the policy is MPOL_PREFERRED, and the
> >     preferred_node is <0, no rebind is necessary.  The "local allocation"
> >     indication is valid in any cpuset.  Existing code will "do the right
> >     thing" because node_remap() will just return the argument node when
> >     it is outside of the valid range of node ids.  However, I think it is
> >     clearer and cleaner to skip the remap explicitly in this case.
> 
> Sounds good. This is on the way to having cpuset relative node 
> numbering???
>  
> > 3)  mpol_to_str() produces a printable, "human readable" string from a
> >     struct mempolicy.  For MPOL_PREFERRED with preferred_node <0,  show
> >     the entire set of valid nodes.  Although, technically, MPOL_PREFERRED
> >     takes only a single node, preferred_node <0 is a local allocation policy,
> >     with the preferred node determined by the context where the task
> >     is executing.  All of the allowed nodes are possible, as the task
> >     migrates amoung the nodes in the cpuset.  Without this change, I believe
> >     that node_set() [via set_bit()] will set bit 31, resulting in a misleading
> >     display.
> 
> Hmmm. But one wants mpol_to_str to represent the memory policy not the 
> context information that may change through migration. What you 
> do there is provide information from the context. You could add the 
> nodemask but I think we need to have some indicator that this policy is 
> referring to the local policy.

True.  I could make mpol_to_str return something like "*" for the
nodemask and document this as "any allowed".

Thoughts?

Lee

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