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 from this list: send the line "unsubscribe linux-numa" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
