Re: [PATCH 3/6] hugetlb: derive huge pages nodes allowed from task mempolicy

[David Rientjes <rientjes@google.com>]

On Thu, 3 Sep 2009, Lee Schermerhorn wrote:

> > This isn't limited to only hugepage code, so a more appropriate name would 
> > probably be better.
> 
> Currently, this function is very much limited only to hugepage code.
> Most [all?] other users of mempolicy just use the alloc_vma_pages() and
> company, w/o cracking open the mempolicy.   I suppose something might
> come along that wants to open code interleaving over this mask, the way
> hugepage code does.  We could generalize it, then.  However, I'm not
> opposed to changing it to something like
> "alloc_nodemask_of_mempolicy()".   I still want to keep it in
> mempolicy.c, tho'.
> 
> Would this work for you?
>   

Yeah, it's not hugepage specific at all so mm/mempolicy.c is the only 
place for it anyway.  I just didn't think it needed `huge' in its name 
since it may get additional callers later.  alloc_nodemask_of_mempolicy() 
certainly sounds like a good generic function with a well defined purpose.

> > It'd probably be better to check for a NULL nodes_allowed either in 
> > set_max_huge_pages() than in hstate_next_node_to_{alloc,free} just for the 
> > cleanliness of the code OR simply return node_online_map from this 
> > function for default policies.
> 
> Yeah, I could pull the test up there to right after we check for a node
> id or task policy, and assign a pointer to node_online_map to
> nodes_allowed.  Then, I'll have to test for that condition before
> calling kfree().  I have no strong feelings about this.   I'll try to
> get this done for V6.  I'd like to get that out this week.
> 

&node_states[N_HIGH_MEMORY] as opposed to &node_online_map.  

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