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

[David Rientjes <rientjes@google.com>]

On Fri, 28 Aug 2009, Lee Schermerhorn wrote:

> Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/mempolicy.c
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/mempolicy.c	2009-08-28 09:21:20.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/mm/mempolicy.c	2009-08-28 09:21:28.000000000 -0400
> @@ -1564,6 +1564,67 @@ struct zonelist *huge_zonelist(struct vm
>  	}
>  	return zl;
>  }
> +
> +/*
> + * huge_mpol_nodes_allowed -- mempolicy extension for huge pages.
> + *
> + * Returns a [pointer to a] nodelist based on the current task's mempolicy
> + * to constraing the allocation and freeing of persistent huge pages
> + * 'Preferred', 'local' and 'interleave' mempolicy will behave more like
> + * 'bind' policy in this context.  An attempt to allocate a persistent huge
> + * page will never "fallback" to another node inside the buddy system
> + * allocator.
> + *
> + * If the task's mempolicy is "default" [NULL], just return NULL for
> + * default behavior.  Otherwise, extract the policy nodemask for 'bind'
> + * or 'interleave' policy or construct a nodemask for 'preferred' or
> + * 'local' policy and return a pointer to a kmalloc()ed nodemask_t.
> + *
> + * N.B., it is the caller's responsibility to free a returned nodemask.
> + */

This isn't limited to only hugepage code, so a more appropriate name would 
probably be better.

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.

Otherwise

Acked-by: David Rientjes <rientjes@google.com>

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