From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3])
	by kanga.kvack.org (Postfix) with ESMTP id 207886B004F
	for <linux-mm@kvack.org>; Fri, 28 Aug 2009 12:00:20 -0400 (EDT)
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Date: Fri, 28 Aug 2009 12:03:14 -0400
Message-Id: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Subject: [PATCH 0/6] hugetlb: V5 constrain allocation/free based on task mempolicy
Sender: owner-linux-mm@kvack.org
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

PATCH 0/6 hugetlb: numa control of persistent huge pages alloc/free

Against:  2.6.31-rc7-mmotm-090827-0057

This is V5 of a series of patches to provide control over the location
of the allocation and freeing of persistent huge pages on a NUMA
platform.

This series uses the task NUMA mempolicy of the task modifying
"nr_hugepages" to constrain the affected nodes.  This method is
based on Mel Gorman's suggestion to use task mempolicy.  One of
the benefits of this method is that it does not *require*
modification to hugeadm(8) to use this feature.  One of the possible
downsides is that task mempolicy is limited by cpuset constraints.

V4 added a subset of the hugepages sysfs attributes to each per
node system device directory under:

	/sys/devices/node/node[0-9]*/hugepages.

The per node attibutes allow direct assignment of a huge page
count on a specific node, regardless of the task's mempolicy or
cpuset constraints.

V5 addresses review comments -- changes described in patch
descriptions.  Should be almost ready for -mm?

Note, I haven't implemented a boot time parameter to constrain the
boot time allocation of huge pages.  This can be added if anyone feels
strongly that it is required.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with ESMTP id 815976B004F
	for <linux-mm@kvack.org>; Fri, 28 Aug 2009 12:00:21 -0400 (EDT)
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Date: Fri, 28 Aug 2009 12:03:21 -0400
Message-Id: <20090828160321.11080.93497.sendpatchset@localhost.localdomain>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Subject: [PATCH 1/6] hugetlb:  rework hstate_next_node_* functions
Sender: owner-linux-mm@kvack.org
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

[PATCH 1/6] hugetlb:  rework hstate_next_node* functions

Against:  2.6.31-rc7-mmotm-090827-0057

V2:
+ cleaned up comments, removed some deemed unnecessary,
  add some suggested by review
+ removed check for !current in huge_mpol_nodes_allowed().
+ added 'current->comm' to warning message in huge_mpol_nodes_allowed().
+ added VM_BUG_ON() assertion in hugetlb.c next_node_allowed() to
  catch out of range node id.
+ add examples to patch description

V3:
+ factored this "cleanup" patch out of V2 patch 2/3
+ moved ahead of patch to add nodes_allowed mask to alloc funcs
  as this patch is somewhat independent from using task mempolicy
  to control huge page allocation and freeing.

Modify the hstate_next_node* functions to allow them to be called to
obtain the "start_nid".  Then, whereas prior to this patch we
unconditionally called hstate_next_node_to_{alloc|free}(), whether
or not we successfully allocated/freed a huge page on the node,
now we only call these functions on failure to alloc/free to advance
to next allowed node.

Factor out the next_node_allowed() function to handle wrap at end
of node_online_map.  In this version, the allowed nodes include all 
of the online nodes.

Acked-by: David Rientjes <rientjes@google.com>
Reviewed-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 mm/hugetlb.c |   70 +++++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 45 insertions(+), 25 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-27 13:12:12.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:21.000000000 -0400
@@ -622,6 +622,20 @@ static struct page *alloc_fresh_huge_pag
 }
 
 /*
+ * common helper function for hstate_next_node_to_{alloc|free}.
+ * return next node in node_online_map, wrapping at end.
+ */
+static int next_node_allowed(int nid)
+{
+	nid = next_node(nid, node_online_map);
+	if (nid == MAX_NUMNODES)
+		nid = first_node(node_online_map);
+	VM_BUG_ON(nid >= MAX_NUMNODES);
+
+	return nid;
+}
+
+/*
  * Use a helper variable to find the next node and then
  * copy it back to next_nid_to_alloc afterwards:
  * otherwise there's a window in which a racer might
@@ -634,12 +648,12 @@ static struct page *alloc_fresh_huge_pag
  */
 static int hstate_next_node_to_alloc(struct hstate *h)
 {
-	int next_nid;
-	next_nid = next_node(h->next_nid_to_alloc, node_online_map);
-	if (next_nid == MAX_NUMNODES)
-		next_nid = first_node(node_online_map);
+	int nid, next_nid;
+
+	nid = h->next_nid_to_alloc;
+	next_nid = next_node_allowed(nid);
 	h->next_nid_to_alloc = next_nid;
-	return next_nid;
+	return nid;
 }
 
 static int alloc_fresh_huge_page(struct hstate *h)
@@ -649,15 +663,17 @@ static int alloc_fresh_huge_page(struct
 	int next_nid;
 	int ret = 0;
 
-	start_nid = h->next_nid_to_alloc;
+	start_nid = hstate_next_node_to_alloc(h);
 	next_nid = start_nid;
 
 	do {
 		page = alloc_fresh_huge_page_node(h, next_nid);
-		if (page)
+		if (page) {
 			ret = 1;
+			break;
+		}
 		next_nid = hstate_next_node_to_alloc(h);
-	} while (!page && next_nid != start_nid);
+	} while (next_nid != start_nid);
 
 	if (ret)
 		count_vm_event(HTLB_BUDDY_PGALLOC);
@@ -668,17 +684,19 @@ static int alloc_fresh_huge_page(struct
 }
 
 /*
- * helper for free_pool_huge_page() - find next node
- * from which to free a huge page
+ * helper for free_pool_huge_page() - return the next node
+ * from which to free a huge page.  Advance the next node id
+ * whether or not we find a free huge page to free so that the
+ * next attempt to free addresses the next node.
  */
 static int hstate_next_node_to_free(struct hstate *h)
 {
-	int next_nid;
-	next_nid = next_node(h->next_nid_to_free, node_online_map);
-	if (next_nid == MAX_NUMNODES)
-		next_nid = first_node(node_online_map);
+	int nid, next_nid;
+
+	nid = h->next_nid_to_free;
+	next_nid = next_node_allowed(nid);
 	h->next_nid_to_free = next_nid;
-	return next_nid;
+	return nid;
 }
 
 /*
@@ -693,7 +711,7 @@ static int free_pool_huge_page(struct hs
 	int next_nid;
 	int ret = 0;
 
-	start_nid = h->next_nid_to_free;
+	start_nid = hstate_next_node_to_free(h);
 	next_nid = start_nid;
 
 	do {
@@ -715,9 +733,10 @@ static int free_pool_huge_page(struct hs
 			}
 			update_and_free_page(h, page);
 			ret = 1;
+			break;
 		}
 		next_nid = hstate_next_node_to_free(h);
-	} while (!ret && next_nid != start_nid);
+	} while (next_nid != start_nid);
 
 	return ret;
 }
@@ -1028,10 +1047,9 @@ int __weak alloc_bootmem_huge_page(struc
 		void *addr;
 
 		addr = __alloc_bootmem_node_nopanic(
-				NODE_DATA(h->next_nid_to_alloc),
+				NODE_DATA(hstate_next_node_to_alloc(h)),
 				huge_page_size(h), huge_page_size(h), 0);
 
-		hstate_next_node_to_alloc(h);
 		if (addr) {
 			/*
 			 * Use the beginning of the huge page to store the
@@ -1167,29 +1185,31 @@ static int adjust_pool_surplus(struct hs
 	VM_BUG_ON(delta != -1 && delta != 1);
 
 	if (delta < 0)
-		start_nid = h->next_nid_to_alloc;
+		start_nid = hstate_next_node_to_alloc(h);
 	else
-		start_nid = h->next_nid_to_free;
+		start_nid = hstate_next_node_to_free(h);
 	next_nid = start_nid;
 
 	do {
 		int nid = next_nid;
 		if (delta < 0)  {
-			next_nid = hstate_next_node_to_alloc(h);
 			/*
 			 * To shrink on this node, there must be a surplus page
 			 */
-			if (!h->surplus_huge_pages_node[nid])
+			if (!h->surplus_huge_pages_node[nid]) {
+				next_nid = hstate_next_node_to_alloc(h);
 				continue;
+			}
 		}
 		if (delta > 0) {
-			next_nid = hstate_next_node_to_free(h);
 			/*
 			 * Surplus cannot exceed the total number of pages
 			 */
 			if (h->surplus_huge_pages_node[nid] >=
-						h->nr_huge_pages_node[nid])
+						h->nr_huge_pages_node[nid]) {
+				next_nid = hstate_next_node_to_free(h);
 				continue;
+			}
 		}
 
 		h->surplus_huge_pages += delta;

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243])
	by kanga.kvack.org (Postfix) with ESMTP id CE3DC6B006A
	for <linux-mm@kvack.org>; Fri, 28 Aug 2009 12:00:27 -0400 (EDT)
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Date: Fri, 28 Aug 2009 12:03:26 -0400
Message-Id: <20090828160326.11080.56814.sendpatchset@localhost.localdomain>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Subject: [PATCH 2/6] hugetlb:  add nodemask arg to huge page alloc, free and surplus adjust fcns
Sender: owner-linux-mm@kvack.org
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

[PATCH 2/6] hugetlb:  add nodemask arg to huge page alloc, free and surplus adjust fcns

Against:  2.6.31-rc7-mmotm-090827-0057

V3:
+ moved this patch to after the "rework" of hstate_next_node_to_...
  functions as this patch is more specific to using task mempolicy
  to control huge page allocation and freeing.

V5:
+ removed now unneeded 'nextnid' from hstate_next_node_to_{alloc|free}
  and updated the stale comments.

In preparation for constraining huge page allocation and freeing by the
controlling task's numa mempolicy, add a "nodes_allowed" nodemask pointer
to the allocate, free and surplus adjustment functions.  For now, pass
NULL to indicate default behavior--i.e., use node_online_map.  A
subsqeuent patch will derive a non-default mask from the controlling 
task's numa mempolicy.

Note that this method of updating the global hstate nr_hugepages under
the constraint of a nodemask simplifies keeping the global state 
consistent--especially the number of persistent and surplus pages
relative to reservations and overcommit limits.  There are undoubtedly
other ways to do this, but this works for both interfaces:  mempolicy
and per node attributes.

Reviewed-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 mm/hugetlb.c |  121 +++++++++++++++++++++++++++++++++++------------------------
 1 file changed, 72 insertions(+), 49 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:21.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:26.000000000 -0400
@@ -622,48 +622,57 @@ static struct page *alloc_fresh_huge_pag
 }
 
 /*
- * common helper function for hstate_next_node_to_{alloc|free}.
- * return next node in node_online_map, wrapping at end.
+ * common helper functions for hstate_next_node_to_{alloc|free}.
+ * We may have allocated or freed a huge page based on a different
+ * nodes_allowed previously, so h->next_node_to_{alloc|free} might
+ * be outside of *nodes_allowed.  Ensure that we use an allowed
+ * node for alloc or free.
  */
-static int next_node_allowed(int nid)
+static int next_node_allowed(int nid, nodemask_t *nodes_allowed)
 {
-	nid = next_node(nid, node_online_map);
+	nid = next_node(nid, *nodes_allowed);
 	if (nid == MAX_NUMNODES)
-		nid = first_node(node_online_map);
+		nid = first_node(*nodes_allowed);
 	VM_BUG_ON(nid >= MAX_NUMNODES);
 
 	return nid;
 }
 
+static int this_node_allowed(int nid, nodemask_t *nodes_allowed)
+{
+	if (!node_isset(nid, *nodes_allowed))
+		nid = next_node_allowed(nid, nodes_allowed);
+	return nid;
+}
+
 /*
- * Use a helper variable to find the next node and then
- * copy it back to next_nid_to_alloc afterwards:
- * otherwise there's a window in which a racer might
- * pass invalid nid MAX_NUMNODES to alloc_pages_exact_node.
- * But we don't need to use a spin_lock here: it really
- * doesn't matter if occasionally a racer chooses the
- * same nid as we do.  Move nid forward in the mask even
- * if we just successfully allocated a hugepage so that
- * the next caller gets hugepages on the next node.
+ * returns the previously saved node ["this node"] from which to
+ * allocate a persistent huge page for the pool and advance the
+ * next node from which to allocate, handling wrap at end of node
+ * mask.  'nodes_allowed' defaults to node_online_map.
  */
-static int hstate_next_node_to_alloc(struct hstate *h)
+static int hstate_next_node_to_alloc(struct hstate *h,
+					nodemask_t *nodes_allowed)
 {
-	int nid, next_nid;
+	int nid;
+
+	if (!nodes_allowed)
+		nodes_allowed = &node_online_map;
+
+	nid = this_node_allowed(h->next_nid_to_alloc, nodes_allowed);
+	h->next_nid_to_alloc = next_node_allowed(nid, nodes_allowed);
 
-	nid = h->next_nid_to_alloc;
-	next_nid = next_node_allowed(nid);
-	h->next_nid_to_alloc = next_nid;
 	return nid;
 }
 
-static int alloc_fresh_huge_page(struct hstate *h)
+static int alloc_fresh_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
 {
 	struct page *page;
 	int start_nid;
 	int next_nid;
 	int ret = 0;
 
-	start_nid = hstate_next_node_to_alloc(h);
+	start_nid = hstate_next_node_to_alloc(h, nodes_allowed);
 	next_nid = start_nid;
 
 	do {
@@ -672,7 +681,7 @@ static int alloc_fresh_huge_page(struct
 			ret = 1;
 			break;
 		}
-		next_nid = hstate_next_node_to_alloc(h);
+		next_nid = hstate_next_node_to_alloc(h, nodes_allowed);
 	} while (next_nid != start_nid);
 
 	if (ret)
@@ -684,18 +693,21 @@ static int alloc_fresh_huge_page(struct
 }
 
 /*
- * helper for free_pool_huge_page() - return the next node
- * from which to free a huge page.  Advance the next node id
- * whether or not we find a free huge page to free so that the
- * next attempt to free addresses the next node.
+ * helper for free_pool_huge_page() - return the previously saved
+ * node ["this node"] from which to free a huge page.  Advance the
+ * next node id whether or not we find a free huge page to free so
+ * that the next attempt to free addresses the next node.
  */
-static int hstate_next_node_to_free(struct hstate *h)
+static int hstate_next_node_to_free(struct hstate *h, nodemask_t *nodes_allowed)
 {
-	int nid, next_nid;
+	int nid;
+
+	if (!nodes_allowed)
+		nodes_allowed = &node_online_map;
+
+	nid = this_node_allowed(h->next_nid_to_free, nodes_allowed);
+	h->next_nid_to_free = next_node_allowed(nid, nodes_allowed);
 
-	nid = h->next_nid_to_free;
-	next_nid = next_node_allowed(nid);
-	h->next_nid_to_free = next_nid;
 	return nid;
 }
 
@@ -705,13 +717,14 @@ static int hstate_next_node_to_free(stru
  * balanced over allowed nodes.
  * Called with hugetlb_lock locked.
  */
-static int free_pool_huge_page(struct hstate *h, bool acct_surplus)
+static int free_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed,
+							 bool acct_surplus)
 {
 	int start_nid;
 	int next_nid;
 	int ret = 0;
 
-	start_nid = hstate_next_node_to_free(h);
+	start_nid = hstate_next_node_to_free(h, nodes_allowed);
 	next_nid = start_nid;
 
 	do {
@@ -735,7 +748,7 @@ static int free_pool_huge_page(struct hs
 			ret = 1;
 			break;
 		}
-		next_nid = hstate_next_node_to_free(h);
+		next_nid = hstate_next_node_to_free(h, nodes_allowed);
 	} while (next_nid != start_nid);
 
 	return ret;
@@ -937,7 +950,7 @@ static void return_unused_surplus_pages(
 	 * on-line nodes for us and will handle the hstate accounting.
 	 */
 	while (nr_pages--) {
-		if (!free_pool_huge_page(h, 1))
+		if (!free_pool_huge_page(h, NULL, 1))
 			break;
 	}
 }
@@ -1047,7 +1060,7 @@ int __weak alloc_bootmem_huge_page(struc
 		void *addr;
 
 		addr = __alloc_bootmem_node_nopanic(
-				NODE_DATA(hstate_next_node_to_alloc(h)),
+				NODE_DATA(hstate_next_node_to_alloc(h, NULL)),
 				huge_page_size(h), huge_page_size(h), 0);
 
 		if (addr) {
@@ -1102,7 +1115,7 @@ static void __init hugetlb_hstate_alloc_
 		if (h->order >= MAX_ORDER) {
 			if (!alloc_bootmem_huge_page(h))
 				break;
-		} else if (!alloc_fresh_huge_page(h))
+		} else if (!alloc_fresh_huge_page(h, NULL))
 			break;
 	}
 	h->max_huge_pages = i;
@@ -1144,16 +1157,22 @@ static void __init report_hugepages(void
 }
 
 #ifdef CONFIG_HIGHMEM
-static void try_to_free_low(struct hstate *h, unsigned long count)
+static void try_to_free_low(struct hstate *h, unsigned long count,
+						nodemask_t *nodes_allowed)
 {
 	int i;
 
 	if (h->order >= MAX_ORDER)
 		return;
 
+	if (!nodes_allowed)
+		nodes_allowed = &node_online_map;
+
 	for (i = 0; i < MAX_NUMNODES; ++i) {
 		struct page *page, *next;
 		struct list_head *freel = &h->hugepage_freelists[i];
+		if (!node_isset(i, *nodes_allowed))
+			continue;
 		list_for_each_entry_safe(page, next, freel, lru) {
 			if (count >= h->nr_huge_pages)
 				return;
@@ -1167,7 +1186,8 @@ static void try_to_free_low(struct hstat
 	}
 }
 #else
-static inline void try_to_free_low(struct hstate *h, unsigned long count)
+static inline void try_to_free_low(struct hstate *h, unsigned long count,
+						nodemask_t *nodes_allowed)
 {
 }
 #endif
@@ -1177,7 +1197,8 @@ static inline void try_to_free_low(struc
  * balanced by operating on them in a round-robin fashion.
  * Returns 1 if an adjustment was made.
  */
-static int adjust_pool_surplus(struct hstate *h, int delta)
+static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
+				int delta)
 {
 	int start_nid, next_nid;
 	int ret = 0;
@@ -1185,9 +1206,9 @@ static int adjust_pool_surplus(struct hs
 	VM_BUG_ON(delta != -1 && delta != 1);
 
 	if (delta < 0)
-		start_nid = hstate_next_node_to_alloc(h);
+		start_nid = hstate_next_node_to_alloc(h, nodes_allowed);
 	else
-		start_nid = hstate_next_node_to_free(h);
+		start_nid = hstate_next_node_to_free(h, nodes_allowed);
 	next_nid = start_nid;
 
 	do {
@@ -1197,7 +1218,8 @@ static int adjust_pool_surplus(struct hs
 			 * To shrink on this node, there must be a surplus page
 			 */
 			if (!h->surplus_huge_pages_node[nid]) {
-				next_nid = hstate_next_node_to_alloc(h);
+				next_nid = hstate_next_node_to_alloc(h,
+								nodes_allowed);
 				continue;
 			}
 		}
@@ -1207,7 +1229,8 @@ static int adjust_pool_surplus(struct hs
 			 */
 			if (h->surplus_huge_pages_node[nid] >=
 						h->nr_huge_pages_node[nid]) {
-				next_nid = hstate_next_node_to_free(h);
+				next_nid = hstate_next_node_to_free(h,
+								nodes_allowed);
 				continue;
 			}
 		}
@@ -1242,7 +1265,7 @@ static unsigned long set_max_huge_pages(
 	 */
 	spin_lock(&hugetlb_lock);
 	while (h->surplus_huge_pages && count > persistent_huge_pages(h)) {
-		if (!adjust_pool_surplus(h, -1))
+		if (!adjust_pool_surplus(h, NULL, -1))
 			break;
 	}
 
@@ -1253,7 +1276,7 @@ static unsigned long set_max_huge_pages(
 		 * and reducing the surplus.
 		 */
 		spin_unlock(&hugetlb_lock);
-		ret = alloc_fresh_huge_page(h);
+		ret = alloc_fresh_huge_page(h, NULL);
 		spin_lock(&hugetlb_lock);
 		if (!ret)
 			goto out;
@@ -1277,13 +1300,13 @@ static unsigned long set_max_huge_pages(
 	 */
 	min_count = h->resv_huge_pages + h->nr_huge_pages - h->free_huge_pages;
 	min_count = max(count, min_count);
-	try_to_free_low(h, min_count);
+	try_to_free_low(h, min_count, NULL);
 	while (min_count < persistent_huge_pages(h)) {
-		if (!free_pool_huge_page(h, 0))
+		if (!free_pool_huge_page(h, NULL, 0))
 			break;
 	}
 	while (count < persistent_huge_pages(h)) {
-		if (!adjust_pool_surplus(h, 1))
+		if (!adjust_pool_surplus(h, NULL, 1))
 			break;
 	}
 out:

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243])
	by kanga.kvack.org (Postfix) with ESMTP id BA8606B0082
	for <linux-mm@kvack.org>; Fri, 28 Aug 2009 12:00:33 -0400 (EDT)
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Date: Fri, 28 Aug 2009 12:03:32 -0400
Message-Id: <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Subject: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from task mempolicy
Sender: owner-linux-mm@kvack.org
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

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

Against: 2.6.31-rc7-mmotm-090827-0057

V2:
+ cleaned up comments, removed some deemed unnecessary,
  add some suggested by review
+ removed check for !current in huge_mpol_nodes_allowed().
+ added 'current->comm' to warning message in huge_mpol_nodes_allowed().
+ added VM_BUG_ON() assertion in hugetlb.c next_node_allowed() to
  catch out of range node id.
+ add examples to patch description

V3: Factored this patch from V2 patch 2/3

V4: added back missing "kfree(nodes_allowed)" in set_max_nr_hugepages()

V5: remove internal '\n' from printk in huge_mpol_nodes_allowed()

This patch derives a "nodes_allowed" node mask from the numa
mempolicy of the task modifying the number of persistent huge
pages to control the allocation, freeing and adjusting of surplus
huge pages.  This mask is derived as follows:

* For "default" [NULL] task mempolicy, a NULL nodemask_t pointer
  is produced.  This will cause the hugetlb subsystem to use
  node_online_map as the "nodes_allowed".  This preserves the
  behavior before this patch.
* For "preferred" mempolicy, including explicit local allocation,
  a nodemask with the single preferred node will be produced. 
  "local" policy will NOT track any internode migrations of the
  task adjusting nr_hugepages.
* For "bind" and "interleave" policy, the mempolicy's nodemask
  will be used.
* Other than to inform the construction of the nodes_allowed node
  mask, the actual mempolicy mode is ignored.  That is, all modes
  behave like interleave over the resulting nodes_allowed mask
  with no "fallback".

Notes:

1) This patch introduces a subtle change in behavior:  huge page
   allocation and freeing will be constrained by any mempolicy
   that the task adjusting the huge page pool inherits from its
   parent.  This policy could come from a distant ancestor.  The
   adminstrator adjusting the huge page pool without explicitly
   specifying a mempolicy via numactl might be surprised by this.
   Additionaly, any mempolicy specified by numactl will be
   constrained by the cpuset in which numactl is invoked.
   Using sysfs per node hugepages attributes to adjust the per
   node persistent huge pages count [subsequent patch] ignores
   mempolicy and cpuset constraints.

2) Hugepages allocated at boot time use the node_online_map.
   An additional patch could implement a temporary boot time
   huge pages nodes_allowed command line parameter.

3) Using mempolicy to control persistent huge page allocation
   and freeing requires no change to hugeadm when invoking
   it via numactl, as shown in the examples below.  However,
   hugeadm could be enhanced to take the allowed nodes as an
   argument and set its task mempolicy itself.  This would allow
   it to detect and warn about any non-default mempolicy that it
   inherited from its parent, thus alleviating the issue described
   in Note 1 above.

See the updated documentation [next patch] for more information
about the implications of this patch.

Examples:

Starting with:

	Node 0 HugePages_Total:     0
	Node 1 HugePages_Total:     0
	Node 2 HugePages_Total:     0
	Node 3 HugePages_Total:     0

Default behavior [with or without this patch] balances persistent
hugepage allocation across nodes [with sufficient contiguous memory]:

	hugeadm --pool-pages-min=2048Kb:32

yields:

	Node 0 HugePages_Total:     8
	Node 1 HugePages_Total:     8
	Node 2 HugePages_Total:     8
	Node 3 HugePages_Total:     8

Applying mempolicy--e.g., with numactl [using '-m' a.k.a.
'--membind' because it allows multiple nodes to be specified
and it's easy to type]--we can allocate huge pages on
individual nodes or sets of nodes.  So, starting from the 
condition above, with 8 huge pages per node:

	numactl -m 2 hugeadm --pool-pages-min=2048Kb:+8

yields:

	Node 0 HugePages_Total:     8
	Node 1 HugePages_Total:     8
	Node 2 HugePages_Total:    16
	Node 3 HugePages_Total:     8

The incremental 8 huge pages were restricted to node 2 by the
specified mempolicy.

Similarly, we can use mempolicy to free persistent huge pages
from specified nodes:

	numactl -m 0,1 hugeadm --pool-pages-min=2048Kb:-8

yields:

	Node 0 HugePages_Total:     4
	Node 1 HugePages_Total:     4
	Node 2 HugePages_Total:    16
	Node 3 HugePages_Total:     8

The 8 huge pages freed were balanced over nodes 0 and 1.

Acked-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/mempolicy.h |    3 ++
 mm/hugetlb.c              |   14 ++++++----
 mm/mempolicy.c            |   61 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 73 insertions(+), 5 deletions(-)

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.
+ */
+nodemask_t *huge_mpol_nodes_allowed(void)
+{
+	nodemask_t *nodes_allowed = NULL;
+	struct mempolicy *mempolicy;
+	int nid;
+
+	if (!current->mempolicy)
+		return NULL;
+
+	mpol_get(current->mempolicy);
+	nodes_allowed = kmalloc(sizeof(*nodes_allowed), GFP_KERNEL);
+	if (!nodes_allowed) {
+		printk(KERN_WARNING "%s unable to allocate nodes allowed mask "
+			"for huge page allocation.  Falling back to default.\n",
+			current->comm);
+		goto out;
+	}
+	nodes_clear(*nodes_allowed);
+
+	mempolicy = current->mempolicy;
+	switch (mempolicy->mode) {
+	case MPOL_PREFERRED:
+		if (mempolicy->flags & MPOL_F_LOCAL)
+			nid = numa_node_id();
+		else
+			nid = mempolicy->v.preferred_node;
+		node_set(nid, *nodes_allowed);
+		break;
+
+	case MPOL_BIND:
+		/* Fall through */
+	case MPOL_INTERLEAVE:
+		*nodes_allowed =  mempolicy->v.nodes;
+		break;
+
+	default:
+		BUG();
+	}
+
+out:
+	mpol_put(current->mempolicy);
+	return nodes_allowed;
+}
 #endif
 
 /* Allocate a page in interleaved policy.
Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/mempolicy.h
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/mempolicy.h	2009-08-28 09:21:20.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/mempolicy.h	2009-08-28 09:21:28.000000000 -0400
@@ -201,6 +201,7 @@ extern void mpol_fix_fork_child_flag(str
 extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
 				unsigned long addr, gfp_t gfp_flags,
 				struct mempolicy **mpol, nodemask_t **nodemask);
+extern nodemask_t *huge_mpol_nodes_allowed(void);
 extern unsigned slab_node(struct mempolicy *policy);
 
 extern enum zone_type policy_zone;
@@ -328,6 +329,8 @@ static inline struct zonelist *huge_zone
 	return node_zonelist(0, gfp_flags);
 }
 
+static inline nodemask_t *huge_mpol_nodes_allowed(void) { return NULL; }
+
 static inline int do_migrate_pages(struct mm_struct *mm,
 			const nodemask_t *from_nodes,
 			const nodemask_t *to_nodes, int flags)
Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:26.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
@@ -1248,10 +1248,13 @@ static int adjust_pool_surplus(struct hs
 static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
 {
 	unsigned long min_count, ret;
+	nodemask_t *nodes_allowed;
 
 	if (h->order >= MAX_ORDER)
 		return h->max_huge_pages;
 
+	nodes_allowed = huge_mpol_nodes_allowed();
+
 	/*
 	 * Increase the pool size
 	 * First take pages out of surplus state.  Then make up the
@@ -1265,7 +1268,7 @@ static unsigned long set_max_huge_pages(
 	 */
 	spin_lock(&hugetlb_lock);
 	while (h->surplus_huge_pages && count > persistent_huge_pages(h)) {
-		if (!adjust_pool_surplus(h, NULL, -1))
+		if (!adjust_pool_surplus(h, nodes_allowed, -1))
 			break;
 	}
 
@@ -1276,7 +1279,7 @@ static unsigned long set_max_huge_pages(
 		 * and reducing the surplus.
 		 */
 		spin_unlock(&hugetlb_lock);
-		ret = alloc_fresh_huge_page(h, NULL);
+		ret = alloc_fresh_huge_page(h, nodes_allowed);
 		spin_lock(&hugetlb_lock);
 		if (!ret)
 			goto out;
@@ -1300,18 +1303,19 @@ static unsigned long set_max_huge_pages(
 	 */
 	min_count = h->resv_huge_pages + h->nr_huge_pages - h->free_huge_pages;
 	min_count = max(count, min_count);
-	try_to_free_low(h, min_count, NULL);
+	try_to_free_low(h, min_count, nodes_allowed);
 	while (min_count < persistent_huge_pages(h)) {
-		if (!free_pool_huge_page(h, NULL, 0))
+		if (!free_pool_huge_page(h, nodes_allowed, 0))
 			break;
 	}
 	while (count < persistent_huge_pages(h)) {
-		if (!adjust_pool_surplus(h, NULL, 1))
+		if (!adjust_pool_surplus(h, nodes_allowed, 1))
 			break;
 	}
 out:
 	ret = persistent_huge_pages(h);
 	spin_unlock(&hugetlb_lock);
+	kfree(nodes_allowed);
 	return ret;
 }
 

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3])
	by kanga.kvack.org (Postfix) with ESMTP id 928146B0085
	for <linux-mm@kvack.org>; Fri, 28 Aug 2009 12:00:39 -0400 (EDT)
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Date: Fri, 28 Aug 2009 12:03:38 -0400
Message-Id: <20090828160338.11080.51282.sendpatchset@localhost.localdomain>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Subject: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
Sender: owner-linux-mm@kvack.org
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

[PATCH 4/6] - hugetlb:  introduce alloc_nodemask_of_node()

Against:  2.6.31-rc7-mmotm-090827-0057

New in V5 of series

Introduce nodemask macro to allocate a nodemask and 
initialize it to contain a single node, using the macro
init_nodemask_of_node() factored out of the nodemask_of_node()
macro.

alloc_nodemask_of_node() coded as a macro to avoid header
dependency hell.

This will be used to construct the huge pages "nodes_allowed"
nodemask for a single node when a persistent huge page
pool page count is modified via a per node sysfs attribute.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/nodemask.h |   20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h	2009-08-28 09:21:19.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h	2009-08-28 09:21:29.000000000 -0400
@@ -245,18 +245,34 @@ static inline int __next_node(int n, con
 	return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
 }
 
+#define init_nodemask_of_nodes(mask, node)				\
+	nodes_clear(*(mask));						\
+	node_set((node), *(mask));
+
 #define nodemask_of_node(node)						\
 ({									\
 	typeof(_unused_nodemask_arg_) m;				\
 	if (sizeof(m) == sizeof(unsigned long)) {			\
 		m.bits[0] = 1UL<<(node);				\
 	} else {							\
-		nodes_clear(m);						\
-		node_set((node), m);					\
+		init_nodemask_of_nodes(&m, (node));			\
 	}								\
 	m;								\
 })
 
+/*
+ * returns pointer to kmalloc()'d nodemask initialized to contain the
+ * specified node.  Caller must free with kfree().
+ */
+#define alloc_nodemask_of_node(node)					\
+({									\
+	typeof(_unused_nodemask_arg_) *nmp;				\
+	nmp = kmalloc(sizeof(*nmp), GFP_KERNEL);			\
+	if (nmp)							\
+		init_nodemask_of_nodes(nmp, (node));			\
+	nmp;								\
+})
+
 #define first_unset_node(mask) __first_unset_node(&(mask))
 static inline int __first_unset_node(const nodemask_t *maskp)
 {

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51])
	by kanga.kvack.org (Postfix) with ESMTP id 45BC36B0088
	for <linux-mm@kvack.org>; Fri, 28 Aug 2009 12:00:46 -0400 (EDT)
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Date: Fri, 28 Aug 2009 12:03:44 -0400
Message-Id: <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Subject: [PATCH 5/6] hugetlb:  add per node hstate attributes
Sender: owner-linux-mm@kvack.org
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

[PATCH 5/6] hugetlb:  register per node hugepages attributes

Against: 2.6.31-rc7-mmotm-090820-1918

V2:  remove dependency on kobject private bitfield.  Search
     global hstates then all per node hstates for kobject
     match in attribute show/store functions.

V3:  rebase atop the mempolicy-based hugepage alloc/free;
     use custom "nodes_allowed" to restrict alloc/free to
     a specific node via per node attributes.  Per node
     attribute overrides mempolicy.  I.e., mempolicy only
     applies to global attributes.

V5:  Fix issues raised by Mel Gorman:
     + add !NUMA versions of hugetlb_[un]register_node()
     + rename 'hi' to 'i' in kobj_to_node_hstate()
     + rename (count, input) to (len, count) in nr_hugepages_store()
     + moved per node hugepages_kobj and hstate_kobjs[] from the
       struct node [sysdev] to hugetlb.c private arrays.
     + changed registration mechanism so that hugetlbfs [a module]
       register its attributes registration callbacks with the node
       driver, eliminating the dependency between the node driver
       and hugetlbfs.  From it's init func, hugetlbfs will register
       all on-line nodes' hugepage sysfs attributes along with
       hugetlbfs' attributes register/unregister functions.  The
       node driver will use these functions to [un]register nodes
       with hugetlbfs on node hot-plug.
     + replaced hugetlb.c private "nodes_allowed_from_node()" with
       [new] generic "alloc_nodemask_of_node()".

V5a: + fix !NUMA register_hugetlbfs_with_node():  don't use
       keyword 'do' as parameter name!

This patch adds the per huge page size control/query attributes
to the per node sysdevs:

/sys/devices/system/node/node<ID>/hugepages/hugepages-<size>/
	nr_hugepages       - r/w
	free_huge_pages    - r/o
	surplus_huge_pages - r/o

The patch attempts to re-use/share as much of the existing
global hstate attribute initialization and handling, and the
"nodes_allowed" constraint processing as possible.
Calling set_max_huge_pages() with no node indicates a change to
global hstate parameters.  In this case, any non-default task
mempolicy will be used to generate the nodes_allowed mask.  A
valid node id indicates an update to that node's hstate 
parameters, and the count argument specifies the target count
for the specified node.  From this info, we compute the target
global count for the hstate and construct a nodes_allowed node
mask contain only the specified node.

Setting the node specific nr_hugepages via the per node attribute
effectively ignores any task mempolicy or cpuset constraints.

With this patch:

(me):ls /sys/devices/system/node/node0/hugepages/hugepages-2048kB
./  ../  free_hugepages  nr_hugepages  surplus_hugepages

Starting from:
Node 0 HugePages_Total:     0
Node 0 HugePages_Free:      0
Node 0 HugePages_Surp:      0
Node 1 HugePages_Total:     0
Node 1 HugePages_Free:      0
Node 1 HugePages_Surp:      0
Node 2 HugePages_Total:     0
Node 2 HugePages_Free:      0
Node 2 HugePages_Surp:      0
Node 3 HugePages_Total:     0
Node 3 HugePages_Free:      0
Node 3 HugePages_Surp:      0
vm.nr_hugepages = 0

Allocate 16 persistent huge pages on node 2:
(me):echo 16 >/sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages

[Note that this is equivalent to:
	numactl -m 2 hugeadmin --pool-pages-min 2M:+16
]

Yields:
Node 0 HugePages_Total:     0
Node 0 HugePages_Free:      0
Node 0 HugePages_Surp:      0
Node 1 HugePages_Total:     0
Node 1 HugePages_Free:      0
Node 1 HugePages_Surp:      0
Node 2 HugePages_Total:    16
Node 2 HugePages_Free:     16
Node 2 HugePages_Surp:      0
Node 3 HugePages_Total:     0
Node 3 HugePages_Free:      0
Node 3 HugePages_Surp:      0
vm.nr_hugepages = 16

Global controls work as expected--reduce pool to 8 persistent huge pages:
(me):echo 8 >/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

Node 0 HugePages_Total:     0
Node 0 HugePages_Free:      0
Node 0 HugePages_Surp:      0
Node 1 HugePages_Total:     0
Node 1 HugePages_Free:      0
Node 1 HugePages_Surp:      0
Node 2 HugePages_Total:     8
Node 2 HugePages_Free:      8
Node 2 HugePages_Surp:      0
Node 3 HugePages_Total:     0
Node 3 HugePages_Free:      0
Node 3 HugePages_Surp:      0

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 drivers/base/node.c  |   33 ++++++
 include/linux/node.h |    8 +
 include/linux/numa.h |    2 
 mm/hugetlb.c         |  245 ++++++++++++++++++++++++++++++++++++++++++++-------
 4 files changed, 258 insertions(+), 30 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/drivers/base/node.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/drivers/base/node.c	2009-08-28 09:21:17.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/drivers/base/node.c	2009-08-28 09:21:31.000000000 -0400
@@ -177,6 +177,37 @@ static ssize_t node_read_distance(struct
 }
 static SYSDEV_ATTR(distance, S_IRUGO, node_read_distance, NULL);
 
+/*
+ * hugetlbfs per node attributes registration interface:
+ * When/if hugetlb[fs] subsystem initializes [sometime after this module],
+ * it will register it's per node attributes for all nodes on-line at that
+ * point.  It will also call register_hugetlbfs_with_node(), below, to
+ * register it's attribute registration functions with this node driver.
+ * Once these hooks have been initialized, the node driver will call into
+ * the hugetlb module to [un]register attributes for hot-plugged nodes.
+ */
+NODE_REGISTRATION_FUNC __hugetlb_register_node;
+NODE_REGISTRATION_FUNC __hugetlb_unregister_node;
+
+static inline void hugetlb_register_node(struct node *node)
+{
+	if (__hugetlb_register_node)
+		__hugetlb_register_node(node);
+}
+
+static inline void hugetlb_unregister_node(struct node *node)
+{
+	if (__hugetlb_unregister_node)
+		__hugetlb_unregister_node(node);
+}
+
+void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC doregister,
+                                  NODE_REGISTRATION_FUNC unregister)
+{
+	__hugetlb_register_node   = doregister;
+	__hugetlb_unregister_node = unregister;
+}
+
 
 /*
  * register_node - Setup a sysfs device for a node.
@@ -200,6 +231,7 @@ int register_node(struct node *node, int
 		sysdev_create_file(&node->sysdev, &attr_distance);
 
 		scan_unevictable_register_node(node);
+		hugetlb_register_node(node);
 	}
 	return error;
 }
@@ -220,6 +252,7 @@ void unregister_node(struct node *node)
 	sysdev_remove_file(&node->sysdev, &attr_distance);
 
 	scan_unevictable_unregister_node(node);
+	hugetlb_unregister_node(node);
 
 	sysdev_unregister(&node->sysdev);
 }
Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:31.000000000 -0400
@@ -24,6 +24,7 @@
 #include <asm/io.h>
 
 #include <linux/hugetlb.h>
+#include <linux/node.h>
 #include "internal.h"
 
 const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
@@ -1245,7 +1246,8 @@ static int adjust_pool_surplus(struct hs
 }
 
 #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
-static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
+static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
+								int nid)
 {
 	unsigned long min_count, ret;
 	nodemask_t *nodes_allowed;
@@ -1253,7 +1255,21 @@ static unsigned long set_max_huge_pages(
 	if (h->order >= MAX_ORDER)
 		return h->max_huge_pages;
 
-	nodes_allowed = huge_mpol_nodes_allowed();
+	if (nid == NO_NODEID_SPECIFIED)
+		nodes_allowed = huge_mpol_nodes_allowed();
+	else {
+		/*
+		 * incoming 'count' is for node 'nid' only, so
+		 * adjust count to global, but restrict alloc/free
+		 * to the specified node.
+		 */
+		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
+		nodes_allowed = alloc_nodemask_of_node(nid);
+		if (!nodes_allowed)
+			printk(KERN_WARNING "%s unable to allocate allowed "
+			       "nodes mask for huge page allocation/free.  "
+			       "Falling back to default.\n", current->comm);
+	}
 
 	/*
 	 * Increase the pool size
@@ -1329,51 +1345,71 @@ out:
 static struct kobject *hugepages_kobj;
 static struct kobject *hstate_kobjs[HUGE_MAX_HSTATE];
 
-static struct hstate *kobj_to_hstate(struct kobject *kobj)
+static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp);
+
+static struct hstate *kobj_to_hstate(struct kobject *kobj, int *nidp)
 {
 	int i;
+
 	for (i = 0; i < HUGE_MAX_HSTATE; i++)
-		if (hstate_kobjs[i] == kobj)
+		if (hstate_kobjs[i] == kobj) {
+			if (nidp)
+				*nidp = NO_NODEID_SPECIFIED;
 			return &hstates[i];
-	BUG();
-	return NULL;
+		}
+
+	return kobj_to_node_hstate(kobj, nidp);
 }
 
 static ssize_t nr_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
-	return sprintf(buf, "%lu\n", h->nr_huge_pages);
+	struct hstate *h;
+	unsigned long nr_huge_pages;
+	int nid;
+
+	h = kobj_to_hstate(kobj, &nid);
+	if (nid == NO_NODEID_SPECIFIED)
+		nr_huge_pages = h->nr_huge_pages;
+	else
+		nr_huge_pages = h->nr_huge_pages_node[nid];
+
+	return sprintf(buf, "%lu\n", nr_huge_pages);
 }
+
 static ssize_t nr_hugepages_store(struct kobject *kobj,
-		struct kobj_attribute *attr, const char *buf, size_t count)
+		struct kobj_attribute *attr, const char *buf, size_t len)
 {
+	unsigned long count;
+	struct hstate *h;
+	int nid;
 	int err;
-	unsigned long input;
-	struct hstate *h = kobj_to_hstate(kobj);
 
-	err = strict_strtoul(buf, 10, &input);
+	err = strict_strtoul(buf, 10, &count);
 	if (err)
 		return 0;
 
-	h->max_huge_pages = set_max_huge_pages(h, input);
+	h = kobj_to_hstate(kobj, &nid);
+	h->max_huge_pages = set_max_huge_pages(h, count, nid);
 
-	return count;
+	return len;
 }
 HSTATE_ATTR(nr_hugepages);
 
 static ssize_t nr_overcommit_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
+	struct hstate *h = kobj_to_hstate(kobj, NULL);
+
 	return sprintf(buf, "%lu\n", h->nr_overcommit_huge_pages);
 }
+
 static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
 		struct kobj_attribute *attr, const char *buf, size_t count)
 {
 	int err;
 	unsigned long input;
-	struct hstate *h = kobj_to_hstate(kobj);
+	struct hstate *h = kobj_to_hstate(kobj, NULL);
 
 	err = strict_strtoul(buf, 10, &input);
 	if (err)
@@ -1390,15 +1426,24 @@ HSTATE_ATTR(nr_overcommit_hugepages);
 static ssize_t free_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
-	return sprintf(buf, "%lu\n", h->free_huge_pages);
+	struct hstate *h;
+	unsigned long free_huge_pages;
+	int nid;
+
+	h = kobj_to_hstate(kobj, &nid);
+	if (nid == NO_NODEID_SPECIFIED)
+		free_huge_pages = h->free_huge_pages;
+	else
+		free_huge_pages = h->free_huge_pages_node[nid];
+
+	return sprintf(buf, "%lu\n", free_huge_pages);
 }
 HSTATE_ATTR_RO(free_hugepages);
 
 static ssize_t resv_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
+	struct hstate *h = kobj_to_hstate(kobj, NULL);
 	return sprintf(buf, "%lu\n", h->resv_huge_pages);
 }
 HSTATE_ATTR_RO(resv_hugepages);
@@ -1406,8 +1451,17 @@ HSTATE_ATTR_RO(resv_hugepages);
 static ssize_t surplus_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
-	return sprintf(buf, "%lu\n", h->surplus_huge_pages);
+	struct hstate *h;
+	unsigned long surplus_huge_pages;
+	int nid;
+
+	h = kobj_to_hstate(kobj, &nid);
+	if (nid == NO_NODEID_SPECIFIED)
+		surplus_huge_pages = h->surplus_huge_pages;
+	else
+		surplus_huge_pages = h->surplus_huge_pages_node[nid];
+
+	return sprintf(buf, "%lu\n", surplus_huge_pages);
 }
 HSTATE_ATTR_RO(surplus_hugepages);
 
@@ -1424,19 +1478,21 @@ static struct attribute_group hstate_att
 	.attrs = hstate_attrs,
 };
 
-static int __init hugetlb_sysfs_add_hstate(struct hstate *h)
+static int __init hugetlb_sysfs_add_hstate(struct hstate *h,
+				struct kobject *parent,
+				struct kobject **hstate_kobjs,
+				struct attribute_group *hstate_attr_group)
 {
 	int retval;
+	int hi = h - hstates;
 
-	hstate_kobjs[h - hstates] = kobject_create_and_add(h->name,
-							hugepages_kobj);
-	if (!hstate_kobjs[h - hstates])
+	hstate_kobjs[hi] = kobject_create_and_add(h->name, parent);
+	if (!hstate_kobjs[hi])
 		return -ENOMEM;
 
-	retval = sysfs_create_group(hstate_kobjs[h - hstates],
-							&hstate_attr_group);
+	retval = sysfs_create_group(hstate_kobjs[hi], hstate_attr_group);
 	if (retval)
-		kobject_put(hstate_kobjs[h - hstates]);
+		kobject_put(hstate_kobjs[hi]);
 
 	return retval;
 }
@@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
 		return;
 
 	for_each_hstate(h) {
-		err = hugetlb_sysfs_add_hstate(h);
+		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
+					 hstate_kobjs, &hstate_attr_group);
 		if (err)
 			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
 								h->name);
 	}
 }
 
+#ifdef CONFIG_NUMA
+
+struct node_hstate {
+	struct kobject		*hugepages_kobj;
+	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
+};
+struct node_hstate node_hstates[MAX_NUMNODES];
+
+static struct attribute *per_node_hstate_attrs[] = {
+	&nr_hugepages_attr.attr,
+	&free_hugepages_attr.attr,
+	&surplus_hugepages_attr.attr,
+	NULL,
+};
+
+static struct attribute_group per_node_hstate_attr_group = {
+	.attrs = per_node_hstate_attrs,
+};
+
+static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
+{
+	int nid;
+
+	for (nid = 0; nid < nr_node_ids; nid++) {
+		struct node_hstate *nhs = &node_hstates[nid];
+		int i;
+		for (i = 0; i < HUGE_MAX_HSTATE; i++)
+			if (nhs->hstate_kobjs[i] == kobj) {
+				if (nidp)
+					*nidp = nid;
+				return &hstates[i];
+			}
+	}
+
+	BUG();
+	return NULL;
+}
+
+void hugetlb_unregister_node(struct node *node)
+{
+	struct hstate *h;
+	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
+
+	if (!nhs->hugepages_kobj)
+		return;
+
+	for_each_hstate(h)
+		if (nhs->hstate_kobjs[h - hstates]) {
+			kobject_put(nhs->hstate_kobjs[h - hstates]);
+			nhs->hstate_kobjs[h - hstates] = NULL;
+		}
+
+	kobject_put(nhs->hugepages_kobj);
+	nhs->hugepages_kobj = NULL;
+}
+
+static void hugetlb_unregister_all_nodes(void)
+{
+	int nid;
+
+	for (nid = 0; nid < nr_node_ids; nid++)
+		hugetlb_unregister_node(&node_devices[nid]);
+
+	register_hugetlbfs_with_node(NULL, NULL);
+}
+
+void hugetlb_register_node(struct node *node)
+{
+	struct hstate *h;
+	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
+	int err;
+
+	if (nhs->hugepages_kobj)
+		return;		/* already allocated */
+
+	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
+							&node->sysdev.kobj);
+	if (!nhs->hugepages_kobj)
+		return;
+
+	for_each_hstate(h) {
+		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
+						nhs->hstate_kobjs,
+						&per_node_hstate_attr_group);
+		if (err) {
+			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
+					" for node %d\n",
+						h->name, node->sysdev.id);
+			hugetlb_unregister_node(node);
+			break;
+		}
+	}
+}
+
+static void hugetlb_register_all_nodes(void)
+{
+	int nid;
+
+	for (nid = 0; nid < nr_node_ids; nid++) {
+		struct node *node = &node_devices[nid];
+		if (node->sysdev.id == nid)
+			hugetlb_register_node(node);
+	}
+
+	register_hugetlbfs_with_node(hugetlb_register_node,
+                                     hugetlb_unregister_node);
+}
+#else	/* !CONFIG_NUMA */
+
+static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
+{
+	BUG();
+	if (nidp)
+		*nidp = -1;
+	return NULL;
+}
+
+static void hugetlb_unregister_all_nodes(void) { }
+
+static void hugetlb_register_all_nodes(void) { }
+
+#endif
+
 static void __exit hugetlb_exit(void)
 {
 	struct hstate *h;
 
+	hugetlb_unregister_all_nodes();
+
 	for_each_hstate(h) {
 		kobject_put(hstate_kobjs[h - hstates]);
 	}
@@ -1496,6 +1678,8 @@ static int __init hugetlb_init(void)
 
 	hugetlb_sysfs_init();
 
+	hugetlb_register_all_nodes();
+
 	return 0;
 }
 module_init(hugetlb_init);
@@ -1598,7 +1782,8 @@ int hugetlb_sysctl_handler(struct ctl_ta
 	proc_doulongvec_minmax(table, write, buffer, length, ppos);
 
 	if (write)
-		h->max_huge_pages = set_max_huge_pages(h, tmp);
+		h->max_huge_pages = set_max_huge_pages(h, tmp,
+		                                       NO_NODEID_SPECIFIED);
 
 	return 0;
 }
Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
@@ -10,4 +10,6 @@
 
 #define MAX_NUMNODES    (1 << NODES_SHIFT)
 
+#define NO_NODEID_SPECIFIED	(-1)
+
 #endif /* _LINUX_NUMA_H */
Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/node.h
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/node.h	2009-08-28 09:21:17.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/node.h	2009-08-28 09:21:31.000000000 -0400
@@ -28,6 +28,7 @@ struct node {
 
 struct memory_block;
 extern struct node node_devices[];
+typedef  void (*NODE_REGISTRATION_FUNC)(struct node *);
 
 extern int register_node(struct node *, int, struct node *);
 extern void unregister_node(struct node *node);
@@ -39,6 +40,8 @@ extern int unregister_cpu_under_node(uns
 extern int register_mem_sect_under_node(struct memory_block *mem_blk,
 						int nid);
 extern int unregister_mem_sect_under_nodes(struct memory_block *mem_blk);
+extern void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC doregister,
+                                         NODE_REGISTRATION_FUNC unregister);
 #else
 static inline int register_one_node(int nid)
 {
@@ -65,6 +68,11 @@ static inline int unregister_mem_sect_un
 {
 	return 0;
 }
+
+static inline void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC reg,
+                                                NODE_REGISTRATION_FUNC unreg)
+{
+}
 #endif
 
 #define to_node(sys_device) container_of(sys_device, struct node, sysdev)

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with ESMTP id C1F4C6B008A
	for <linux-mm@kvack.org>; Fri, 28 Aug 2009 12:00:52 -0400 (EDT)
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Date: Fri, 28 Aug 2009 12:03:51 -0400
Message-Id: <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Subject: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy based management.
Sender: owner-linux-mm@kvack.org
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

[PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy based management.

Against: 2.6.31-rc7-mmotm-090827-0057

V2:  Add brief description of per node attributes.

This patch updates the kernel huge tlb documentation to describe the
numa memory policy based huge page management.  Additionaly, the patch
includes a fair amount of rework to improve consistency, eliminate
duplication and set the context for documenting the memory policy
interaction.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 Documentation/vm/hugetlbpage.txt |  257 ++++++++++++++++++++++++++-------------
 1 file changed, 172 insertions(+), 85 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:16.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:32.000000000 -0400
@@ -11,23 +11,21 @@ This optimization is more critical now a
 (several GBs) are more readily available.
 
 Users can use the huge page support in Linux kernel by either using the mmap
-system call or standard SYSv shared memory system calls (shmget, shmat).
+system call or standard SYSV shared memory system calls (shmget, shmat).
 
 First the Linux kernel needs to be built with the CONFIG_HUGETLBFS
 (present under "File systems") and CONFIG_HUGETLB_PAGE (selected
 automatically when CONFIG_HUGETLBFS is selected) configuration
 options.
 
-The kernel built with huge page support should show the number of configured
-huge pages in the system by running the "cat /proc/meminfo" command.
+The /proc/meminfo file provides information about the total number of hugetlb
+pages preallocated in the kernel's huge page pool.  It also displays
+information about the number of free, reserved and surplus huge pages and the
+[default] huge page size.  The huge page size is needed for generating the
+proper alignment and size of the arguments to system calls that map huge page
+regions.
 
-/proc/meminfo also provides information about the total number of hugetlb
-pages configured in the kernel.  It also displays information about the
-number of free hugetlb pages at any time.  It also displays information about
-the configured huge page size - this is needed for generating the proper
-alignment and size of the arguments to the above system calls.
-
-The output of "cat /proc/meminfo" will have lines like:
+The output of "cat /proc/meminfo" will include lines like:
 
 .....
 HugePages_Total: vvv
@@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
 /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
 in the kernel.
 
-/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
-pages in the kernel.  Super user can dynamically request more (or free some
-pre-configured) huge pages.
-The allocation (or deallocation) of hugetlb pages is possible only if there are
-enough physically contiguous free pages in system (freeing of huge pages is
-possible only if there are enough hugetlb pages free that can be transferred
-back to regular memory pool).
-
-Pages that are used as hugetlb pages are reserved inside the kernel and cannot
-be used for other purposes.
-
-Once the kernel with Hugetlb page support is built and running, a user can
-use either the mmap system call or shared memory system calls to start using
-the huge pages.  It is required that the system administrator preallocate
-enough memory for huge page purposes.
-
-The administrator can preallocate huge pages on the kernel boot command line by
-specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
-requested.  This is the most reliable method for preallocating huge pages as
-memory has not yet become fragmented.
+/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
+allocated in the kernel's huge page pool.  These are called "persistent"
+huge pages.  A user with root privileges can dynamically allocate more or
+free some persistent huge pages by increasing or decreasing the value of
+'nr_hugepages'.
+
+Pages that are used as huge pages are reserved inside the kernel and cannot
+be used for other purposes.  Huge pages can not be swapped out under
+memory pressure.
+
+Once a number of huge pages have been pre-allocated to the kernel huge page
+pool, a user with appropriate privilege can use either the mmap system call
+or shared memory system calls to use the huge pages.  See the discussion of
+Using Huge Pages, below
+
+The administrator can preallocate persistent huge pages on the kernel boot
+command line by specifying the "hugepages=N" parameter, where 'N' = the
+number of requested huge pages requested.  This is the most reliable method
+or preallocating huge pages as memory has not yet become fragmented.
 
 Some platforms support multiple huge page sizes.  To preallocate huge pages
 of a specific size, one must preceed the huge pages boot command parameters
@@ -80,19 +77,24 @@ with a huge page size selection paramete
 be specified in bytes with optional scale suffix [kKmMgG].  The default huge
 page size may be selected with the "default_hugepagesz=<size>" boot parameter.
 
-/proc/sys/vm/nr_hugepages indicates the current number of configured [default
-size] hugetlb pages in the kernel.  Super user can dynamically request more
-(or free some pre-configured) huge pages.
-
-Use the following command to dynamically allocate/deallocate default sized
-huge pages:
+When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages
+indicates the current number of pre-allocated huge pages of the default size.
+Thus, one can use the following command to dynamically allocate/deallocate
+default sized persistent huge pages:
 
 	echo 20 > /proc/sys/vm/nr_hugepages
 
-This command will try to configure 20 default sized huge pages in the system.
+This command will try to adjust the number of default sized huge pages in the
+huge page pool to 20, allocating or freeing huge pages, as required.
+
 On a NUMA platform, the kernel will attempt to distribute the huge page pool
-over the all on-line nodes.  These huge pages, allocated when nr_hugepages
-is increased, are called "persistent huge pages".
+over the all the nodes specified by the NUMA memory policy of the task that
+modifies nr_hugepages that contain sufficient available contiguous memory.
+These nodes are called the huge pages "allowed nodes".  The default for the
+huge pages allowed nodes--when the task has default memory policy--is all
+on-line nodes.  See the discussion below of the interaction of task memory
+policy, cpusets and per node attributes with the allocation and freeing of
+persistent huge pages.
 
 The success or failure of huge page allocation depends on the amount of
 physically contiguous memory that is preset in system at the time of the
@@ -101,11 +103,11 @@ some nodes in a NUMA system, it will att
 allocating extra pages on other nodes with sufficient available contiguous
 memory, if any.
 
-System administrators may want to put this command in one of the local rc init
-files.  This will enable the kernel to request huge pages early in the boot
-process when the possibility of getting physical contiguous pages is still
-very high.  Administrators can verify the number of huge pages actually
-allocated by checking the sysctl or meminfo.  To check the per node
+System administrators may want to put this command in one of the local rc
+init files.  This will enable the kernel to preallocate huge pages early in
+the boot process when the possibility of getting physical contiguous pages
+is still very high.  Administrators can verify the number of huge pages
+actually allocated by checking the sysctl or meminfo.  To check the per node
 distribution of huge pages in a NUMA system, use:
 
 	cat /sys/devices/system/node/node*/meminfo | fgrep Huge
@@ -113,39 +115,40 @@ distribution of huge pages in a NUMA sys
 /proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of
 huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are
 requested by applications.  Writing any non-zero value into this file
-indicates that the hugetlb subsystem is allowed to try to obtain "surplus"
-huge pages from the buddy allocator, when the normal pool is exhausted. As
-these surplus huge pages go out of use, they are freed back to the buddy
-allocator.
+indicates that the hugetlb subsystem is allowed to try to obtain that
+number of "surplus" huge pages from the kernel's normal page pool, when the
+persistent huge page pool is exhausted. As these surplus huge pages become
+unused, they are freed back to the kernel's normal page pool.
 
-When increasing the huge page pool size via nr_hugepages, any surplus
+When increasing the huge page pool size via nr_hugepages, any existing surplus
 pages will first be promoted to persistent huge pages.  Then, additional
 huge pages will be allocated, if necessary and if possible, to fulfill
-the new huge page pool size.
+the new persistent huge page pool size.
 
 The administrator may shrink the pool of preallocated huge pages for
 the default huge page size by setting the nr_hugepages sysctl to a
 smaller value.  The kernel will attempt to balance the freeing of huge pages
-across all on-line nodes.  Any free huge pages on the selected nodes will
-be freed back to the buddy allocator.
-
-Caveat: Shrinking the pool via nr_hugepages such that it becomes less
-than the number of huge pages in use will convert the balance to surplus
-huge pages even if it would exceed the overcommit value.  As long as
-this condition holds, however, no more surplus huge pages will be
-allowed on the system until one of the two sysctls are increased
-sufficiently, or the surplus huge pages go out of use and are freed.
+across all nodes in the memory policy of the task modifying nr_hugepages.
+Any free huge pages on the selected nodes will be freed back to the kernel's
+normal page pool.
+
+Caveat: Shrinking the persistent huge page pool via nr_hugepages such that
+it becomes less than the number of huge pages in use will convert the balance
+of the in-use huge pages to surplus huge pages.  This will occur even if
+the number of surplus pages it would exceed the overcommit value.  As long as
+this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is
+increased sufficiently, or the surplus huge pages go out of use and are freed--
+no more surplus huge pages will be allowed to be allocated.
 
 With support for multiple huge page pools at run-time available, much of
-the huge page userspace interface has been duplicated in sysfs. The above
-information applies to the default huge page size which will be
-controlled by the /proc interfaces for backwards compatibility. The root
-huge page control directory in sysfs is:
+the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs.
+The /proc interfaces discussed above have been retained for backwards
+compatibility. The root huge page control directory in sysfs is:
 
 	/sys/kernel/mm/hugepages
 
 For each huge page size supported by the running kernel, a subdirectory
-will exist, of the form
+will exist, of the form:
 
 	hugepages-${size}kB
 
@@ -159,6 +162,98 @@ Inside each of these directories, the sa
 
 which function as described above for the default huge page-sized case.
 
+
+Interaction of Task Memory Policy with Huge Page Allocation/Freeing:
+
+Whether huge pages are allocated and freed via the /proc interface or
+the /sysfs interface, the NUMA nodes from which huge pages are allocated
+or freed are controlled by the NUMA memory policy of the task that modifies
+the nr_hugepages parameter.  [nr_overcommit_hugepages is a global limit.]
+
+The recommended method to allocate or free huge pages to/from the kernel
+huge page pool, using the nr_hugepages example above, is:
+
+    numactl --interleave <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
+
+or, more succinctly:
+
+    numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
+
+This will allocate or free abs(20 - nr_hugepages) to or from the nodes
+specified in <node-list>, depending on whether nr_hugepages is initially
+less than or greater than 20, respectively.  No huge pages will be
+allocated nor freed on any node not included in the specified <node-list>.
+
+Any memory policy mode--bind, preferred, local or interleave--may be
+used.  The effect on persistent huge page allocation will be as follows:
+
+1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt],
+   persistent huge pages will be distributed across the node or nodes
+   specified in the mempolicy as if "interleave" had been specified.
+   However, if a node in the policy does not contain sufficient contiguous
+   memory for a huge page, the allocation will not "fallback" to the nearest
+   neighbor node with sufficient contiguous memory.  To do this would cause
+   undesirable imbalance in the distribution of the huge page pool, or
+   possibly, allocation of persistent huge pages on nodes not allowed by
+   the task's memory policy.
+
+2) One or more nodes may be specified with the bind or interleave policy.
+   If more than one node is specified with the preferred policy, only the
+   lowest numeric id will be used.  Local policy will select the node where
+   the task is running at the time the nodes_allowed mask is constructed.
+
+3) For local policy to be deterministic, the task must be bound to a cpu or
+   cpus in a single node.  Otherwise, the task could be migrated to some
+   other node at any time after launch and the resulting node will be
+   indeterminate.  Thus, local policy is not very useful for this purpose.
+   Any of the other mempolicy modes may be used to specify a single node.
+
+4) The nodes allowed mask will be derived from any non-default task mempolicy,
+   whether this policy was set explicitly by the task itself or one of its
+   ancestors, such as numactl.  This means that if the task is invoked from a
+   shell with non-default policy, that policy will be used.  One can specify a
+   node list of "all" with numactl --interleave or --membind [-m] to achieve
+   interleaving over all nodes in the system or cpuset.
+
+5) Any task mempolicy specifed--e.g., using numactl--will be constrained by
+   the resource limits of any cpuset in which the task runs.  Thus, there will
+   be no way for a task with non-default policy running in a cpuset with a
+   subset of the system nodes to allocate huge pages outside the cpuset
+   without first moving to a cpuset that contains all of the desired nodes.
+
+6) Hugepages allocated at boot time always use the node_online_map.
+
+
+Per Node Hugepages Attributes
+
+A subset of the contents of the root huge page control directory in sysfs,
+described above, has been replicated under each "node" system device in:
+
+	/sys/devices/system/node/node[0-9]*/hugepages/
+
+Under this directory, the subdirectory for each supported huge page size
+contains the following attribute files:
+
+	nr_hugepages
+	free_hugepages
+	surplus_hugepages
+
+The free_' and surplus_' attribute files are read-only.  They return the number
+of free and surplus [overcommitted] huge pages, respectively, on the parent
+node.
+
+The nr_hugepages attribute will return the total number of huge pages on the
+specified node.  When this attribute is written, the number of persistent huge
+pages on the parent node will be adjusted to the specified value, if sufficient
+resources exist, regardless of the task's mempolicy or cpuset constraints.
+
+Note that the number of overcommit and reserve pages remain global quantities,
+as we don't know until fault time, when the faulting task's mempolicy is applied,
+from which node the huge page allocation will be attempted.
+
+
+Using Huge Pages:
+
 If the user applications are going to request huge pages using mmap system
 call, then it is required that system administrator mount a file system of
 type hugetlbfs:
@@ -206,9 +301,11 @@ map_hugetlb.c.
  * requesting huge pages.
  *
  * For the ia64 architecture, the Linux kernel reserves Region number 4 for
- * huge pages.  That means the addresses starting with 0x800000... will need
- * to be specified.  Specifying a fixed address is not required on ppc64,
- * i386 or x86_64.
+ * huge pages.  That means that if one requires a fixed address, a huge page
+ * aligned address starting with 0x800000... will be required.  If a fixed
+ * address is not required, the kernel will select an address in the proper
+ * range.
+ * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
  *
  * Note: The default shared memory limit is quite low on many kernels,
  * you may need to increase it via:
@@ -237,14 +334,8 @@ map_hugetlb.c.
 
 #define dprintf(x)  printf(x)
 
-/* Only ia64 requires this */
-#ifdef __ia64__
-#define ADDR (void *)(0x8000000000000000UL)
-#define SHMAT_FLAGS (SHM_RND)
-#else
-#define ADDR (void *)(0x0UL)
+#define ADDR (void *)(0x0UL)	/* let kernel choose address */
 #define SHMAT_FLAGS (0)
-#endif
 
 int main(void)
 {
@@ -302,10 +393,12 @@ int main(void)
  * example, the app is requesting memory of size 256MB that is backed by
  * huge pages.
  *
- * For ia64 architecture, Linux kernel reserves Region number 4 for huge pages.
- * That means the addresses starting with 0x800000... will need to be
- * specified.  Specifying a fixed address is not required on ppc64, i386
- * or x86_64.
+ * For the ia64 architecture, the Linux kernel reserves Region number 4 for
+ * huge pages.  That means that if one requires a fixed address, a huge page
+ * aligned address starting with 0x800000... will be required.  If a fixed
+ * address is not required, the kernel will select an address in the proper
+ * range.
+ * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
  */
 #include <stdlib.h>
 #include <stdio.h>
@@ -317,14 +410,8 @@ int main(void)
 #define LENGTH (256UL*1024*1024)
 #define PROTECTION (PROT_READ | PROT_WRITE)
 
-/* Only ia64 requires this */
-#ifdef __ia64__
-#define ADDR (void *)(0x8000000000000000UL)
-#define FLAGS (MAP_SHARED | MAP_FIXED)
-#else
-#define ADDR (void *)(0x0UL)
+#define ADDR (void *)(0x0UL)	/* let kernel choose address */
 #define FLAGS (MAP_SHARED)
-#endif
 
 void check_bytes(char *addr)
 {

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35])
	by kanga.kvack.org (Postfix) with ESMTP id 6F9796B004F
	for <linux-mm@kvack.org>; Tue,  1 Sep 2009 10:47:16 -0400 (EDT)
Date: Tue, 1 Sep 2009 15:47:19 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from
	task mempolicy
Message-ID: <20090901144719.GA7548@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Fri, Aug 28, 2009 at 12:03:32PM -0400, Lee Schermerhorn wrote:
> [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from task mempolicy
> 
> Against: 2.6.31-rc7-mmotm-090827-0057
> 
> V2:
> + cleaned up comments, removed some deemed unnecessary,
>   add some suggested by review
> + removed check for !current in huge_mpol_nodes_allowed().
> + added 'current->comm' to warning message in huge_mpol_nodes_allowed().
> + added VM_BUG_ON() assertion in hugetlb.c next_node_allowed() to
>   catch out of range node id.
> + add examples to patch description
> 
> V3: Factored this patch from V2 patch 2/3
> 
> V4: added back missing "kfree(nodes_allowed)" in set_max_nr_hugepages()
> 
> V5: remove internal '\n' from printk in huge_mpol_nodes_allowed()
> 
> This patch derives a "nodes_allowed" node mask from the numa
> mempolicy of the task modifying the number of persistent huge
> pages to control the allocation, freeing and adjusting of surplus
> huge pages.  This mask is derived as follows:
> 
> * For "default" [NULL] task mempolicy, a NULL nodemask_t pointer
>   is produced.  This will cause the hugetlb subsystem to use
>   node_online_map as the "nodes_allowed".  This preserves the
>   behavior before this patch.
> * For "preferred" mempolicy, including explicit local allocation,
>   a nodemask with the single preferred node will be produced. 
>   "local" policy will NOT track any internode migrations of the
>   task adjusting nr_hugepages.
> * For "bind" and "interleave" policy, the mempolicy's nodemask
>   will be used.
> * Other than to inform the construction of the nodes_allowed node
>   mask, the actual mempolicy mode is ignored.  That is, all modes
>   behave like interleave over the resulting nodes_allowed mask
>   with no "fallback".
> 
> Notes:
> 
> 1) This patch introduces a subtle change in behavior:  huge page
>    allocation and freeing will be constrained by any mempolicy
>    that the task adjusting the huge page pool inherits from its
>    parent.  This policy could come from a distant ancestor.  The
>    adminstrator adjusting the huge page pool without explicitly
>    specifying a mempolicy via numactl might be surprised by this.
>    Additionaly, any mempolicy specified by numactl will be
>    constrained by the cpuset in which numactl is invoked.
>    Using sysfs per node hugepages attributes to adjust the per
>    node persistent huge pages count [subsequent patch] ignores
>    mempolicy and cpuset constraints.
> 
> 2) Hugepages allocated at boot time use the node_online_map.
>    An additional patch could implement a temporary boot time
>    huge pages nodes_allowed command line parameter.
> 
> 3) Using mempolicy to control persistent huge page allocation
>    and freeing requires no change to hugeadm when invoking
>    it via numactl, as shown in the examples below.  However,
>    hugeadm could be enhanced to take the allowed nodes as an
>    argument and set its task mempolicy itself.  This would allow
>    it to detect and warn about any non-default mempolicy that it
>    inherited from its parent, thus alleviating the issue described
>    in Note 1 above.
> 
> See the updated documentation [next patch] for more information
> about the implications of this patch.
> 
> Examples:
> 
> Starting with:
> 
> 	Node 0 HugePages_Total:     0
> 	Node 1 HugePages_Total:     0
> 	Node 2 HugePages_Total:     0
> 	Node 3 HugePages_Total:     0
> 
> Default behavior [with or without this patch] balances persistent
> hugepage allocation across nodes [with sufficient contiguous memory]:
> 
> 	hugeadm --pool-pages-min=2048Kb:32
> 
> yields:
> 
> 	Node 0 HugePages_Total:     8
> 	Node 1 HugePages_Total:     8
> 	Node 2 HugePages_Total:     8
> 	Node 3 HugePages_Total:     8
> 
> Applying mempolicy--e.g., with numactl [using '-m' a.k.a.
> '--membind' because it allows multiple nodes to be specified
> and it's easy to type]--we can allocate huge pages on
> individual nodes or sets of nodes.  So, starting from the 
> condition above, with 8 huge pages per node:
> 
> 	numactl -m 2 hugeadm --pool-pages-min=2048Kb:+8
> 
> yields:
> 
> 	Node 0 HugePages_Total:     8
> 	Node 1 HugePages_Total:     8
> 	Node 2 HugePages_Total:    16
> 	Node 3 HugePages_Total:     8
> 
> The incremental 8 huge pages were restricted to node 2 by the
> specified mempolicy.
> 
> Similarly, we can use mempolicy to free persistent huge pages
> from specified nodes:
> 
> 	numactl -m 0,1 hugeadm --pool-pages-min=2048Kb:-8
> 
> yields:
> 
> 	Node 0 HugePages_Total:     4
> 	Node 1 HugePages_Total:     4
> 	Node 2 HugePages_Total:    16
> 	Node 3 HugePages_Total:     8
> 
> The 8 huge pages freed were balanced over nodes 0 and 1.
> 
> Acked-by: Mel Gorman <mel@csn.ul.ie>
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 

This seems to behave as advertised and I could spot no other problems in
the code so make that a;

Reviewed-by: Mel Gorman <mel@csn.ul.ie>

As an aside, I think the ordering of the signed-offs, acks and reviews
are in the wrong order. The ordering of the lines is the order people
were involved in. You are the first as the author and I'm the second so
it should be

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
Reviewed-by: Mel Gorman <mel@csn.ul.ie>

rather than the other way around.

>  include/linux/mempolicy.h |    3 ++
>  mm/hugetlb.c              |   14 ++++++----
>  mm/mempolicy.c            |   61 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 73 insertions(+), 5 deletions(-)
> 
> 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.
> + */
> +nodemask_t *huge_mpol_nodes_allowed(void)
> +{
> +	nodemask_t *nodes_allowed = NULL;
> +	struct mempolicy *mempolicy;
> +	int nid;
> +
> +	if (!current->mempolicy)
> +		return NULL;
> +
> +	mpol_get(current->mempolicy);
> +	nodes_allowed = kmalloc(sizeof(*nodes_allowed), GFP_KERNEL);
> +	if (!nodes_allowed) {
> +		printk(KERN_WARNING "%s unable to allocate nodes allowed mask "
> +			"for huge page allocation.  Falling back to default.\n",
> +			current->comm);
> +		goto out;
> +	}
> +	nodes_clear(*nodes_allowed);
> +
> +	mempolicy = current->mempolicy;
> +	switch (mempolicy->mode) {
> +	case MPOL_PREFERRED:
> +		if (mempolicy->flags & MPOL_F_LOCAL)
> +			nid = numa_node_id();
> +		else
> +			nid = mempolicy->v.preferred_node;
> +		node_set(nid, *nodes_allowed);
> +		break;
> +
> +	case MPOL_BIND:
> +		/* Fall through */
> +	case MPOL_INTERLEAVE:
> +		*nodes_allowed =  mempolicy->v.nodes;
> +		break;
> +
> +	default:
> +		BUG();
> +	}
> +
> +out:
> +	mpol_put(current->mempolicy);
> +	return nodes_allowed;
> +}
>  #endif
>  
>  /* Allocate a page in interleaved policy.
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/mempolicy.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/mempolicy.h	2009-08-28 09:21:20.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/mempolicy.h	2009-08-28 09:21:28.000000000 -0400
> @@ -201,6 +201,7 @@ extern void mpol_fix_fork_child_flag(str
>  extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
>  				unsigned long addr, gfp_t gfp_flags,
>  				struct mempolicy **mpol, nodemask_t **nodemask);
> +extern nodemask_t *huge_mpol_nodes_allowed(void);
>  extern unsigned slab_node(struct mempolicy *policy);
>  
>  extern enum zone_type policy_zone;
> @@ -328,6 +329,8 @@ static inline struct zonelist *huge_zone
>  	return node_zonelist(0, gfp_flags);
>  }
>  
> +static inline nodemask_t *huge_mpol_nodes_allowed(void) { return NULL; }
> +
>  static inline int do_migrate_pages(struct mm_struct *mm,
>  			const nodemask_t *from_nodes,
>  			const nodemask_t *to_nodes, int flags)
> Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:26.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
> @@ -1248,10 +1248,13 @@ static int adjust_pool_surplus(struct hs
>  static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
>  {
>  	unsigned long min_count, ret;
> +	nodemask_t *nodes_allowed;
>  
>  	if (h->order >= MAX_ORDER)
>  		return h->max_huge_pages;
>  
> +	nodes_allowed = huge_mpol_nodes_allowed();
> +
>  	/*
>  	 * Increase the pool size
>  	 * First take pages out of surplus state.  Then make up the
> @@ -1265,7 +1268,7 @@ static unsigned long set_max_huge_pages(
>  	 */
>  	spin_lock(&hugetlb_lock);
>  	while (h->surplus_huge_pages && count > persistent_huge_pages(h)) {
> -		if (!adjust_pool_surplus(h, NULL, -1))
> +		if (!adjust_pool_surplus(h, nodes_allowed, -1))
>  			break;
>  	}
>  
> @@ -1276,7 +1279,7 @@ static unsigned long set_max_huge_pages(
>  		 * and reducing the surplus.
>  		 */
>  		spin_unlock(&hugetlb_lock);
> -		ret = alloc_fresh_huge_page(h, NULL);
> +		ret = alloc_fresh_huge_page(h, nodes_allowed);
>  		spin_lock(&hugetlb_lock);
>  		if (!ret)
>  			goto out;
> @@ -1300,18 +1303,19 @@ static unsigned long set_max_huge_pages(
>  	 */
>  	min_count = h->resv_huge_pages + h->nr_huge_pages - h->free_huge_pages;
>  	min_count = max(count, min_count);
> -	try_to_free_low(h, min_count, NULL);
> +	try_to_free_low(h, min_count, nodes_allowed);
>  	while (min_count < persistent_huge_pages(h)) {
> -		if (!free_pool_huge_page(h, NULL, 0))
> +		if (!free_pool_huge_page(h, nodes_allowed, 0))
>  			break;
>  	}
>  	while (count < persistent_huge_pages(h)) {
> -		if (!adjust_pool_surplus(h, NULL, 1))
> +		if (!adjust_pool_surplus(h, nodes_allowed, 1))
>  			break;
>  	}
>  out:
>  	ret = persistent_huge_pages(h);
>  	spin_unlock(&hugetlb_lock);
> +	kfree(nodes_allowed);
>  	return ret;
>  }
>  
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51])
	by kanga.kvack.org (Postfix) with ESMTP id 328BD6B004D
	for <linux-mm@kvack.org>; Tue,  1 Sep 2009 10:49:27 -0400 (EDT)
Date: Tue, 1 Sep 2009 15:49:32 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
Message-ID: <20090901144932.GB7548@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160338.11080.51282.sendpatchset@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20090828160338.11080.51282.sendpatchset@localhost.localdomain>
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Fri, Aug 28, 2009 at 12:03:38PM -0400, Lee Schermerhorn wrote:
> [PATCH 4/6] - hugetlb:  introduce alloc_nodemask_of_node()
> 
> Against:  2.6.31-rc7-mmotm-090827-0057
> 
> New in V5 of series
> 
> Introduce nodemask macro to allocate a nodemask and 
> initialize it to contain a single node, using the macro
> init_nodemask_of_node() factored out of the nodemask_of_node()
> macro.
> 
> alloc_nodemask_of_node() coded as a macro to avoid header
> dependency hell.
> 
> This will be used to construct the huge pages "nodes_allowed"
> nodemask for a single node when a persistent huge page
> pool page count is modified via a per node sysfs attribute.
> 
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 
>  include/linux/nodemask.h |   20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h	2009-08-28 09:21:19.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h	2009-08-28 09:21:29.000000000 -0400
> @@ -245,18 +245,34 @@ static inline int __next_node(int n, con
>  	return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
>  }
>  
> +#define init_nodemask_of_nodes(mask, node)				\
> +	nodes_clear(*(mask));						\
> +	node_set((node), *(mask));
> +

Is the done thing to either make this a static inline or else wrap it in
a do { } while(0) ? The reasoning being that if this is used as part of an
another statement (e.g. a for loop) that it'll actually compile instead of
throw up weird error messages.

>  #define nodemask_of_node(node)						\
>  ({									\
>  	typeof(_unused_nodemask_arg_) m;				\
>  	if (sizeof(m) == sizeof(unsigned long)) {			\
>  		m.bits[0] = 1UL<<(node);				\
>  	} else {							\
> -		nodes_clear(m);						\
> -		node_set((node), m);					\
> +		init_nodemask_of_nodes(&m, (node));			\
>  	}								\
>  	m;								\
>  })
>  
> +/*
> + * returns pointer to kmalloc()'d nodemask initialized to contain the
> + * specified node.  Caller must free with kfree().
> + */
> +#define alloc_nodemask_of_node(node)					\
> +({									\
> +	typeof(_unused_nodemask_arg_) *nmp;				\
> +	nmp = kmalloc(sizeof(*nmp), GFP_KERNEL);			\
> +	if (nmp)							\
> +		init_nodemask_of_nodes(nmp, (node));			\
> +	nmp;								\
> +})
> +

Otherwise, it looks ok.

>  #define first_unset_node(mask) __first_unset_node(&(mask))
>  static inline int __first_unset_node(const nodemask_t *maskp)
>  {
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35])
	by kanga.kvack.org (Postfix) with ESMTP id BFA286B004F
	for <linux-mm@kvack.org>; Tue,  1 Sep 2009 11:20:10 -0400 (EDT)
Date: Tue, 1 Sep 2009 16:20:15 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
Message-ID: <20090901152015.GC7548@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Fri, Aug 28, 2009 at 12:03:44PM -0400, Lee Schermerhorn wrote:
> [PATCH 5/6] hugetlb:  register per node hugepages attributes
> 
> Against: 2.6.31-rc7-mmotm-090820-1918
> 
> V2:  remove dependency on kobject private bitfield.  Search
>      global hstates then all per node hstates for kobject
>      match in attribute show/store functions.
> 
> V3:  rebase atop the mempolicy-based hugepage alloc/free;
>      use custom "nodes_allowed" to restrict alloc/free to
>      a specific node via per node attributes.  Per node
>      attribute overrides mempolicy.  I.e., mempolicy only
>      applies to global attributes.
> 
> V5:  Fix issues raised by Mel Gorman:
>      + add !NUMA versions of hugetlb_[un]register_node()
>      + rename 'hi' to 'i' in kobj_to_node_hstate()
>      + rename (count, input) to (len, count) in nr_hugepages_store()
>      + moved per node hugepages_kobj and hstate_kobjs[] from the
>        struct node [sysdev] to hugetlb.c private arrays.
>      + changed registration mechanism so that hugetlbfs [a module]
>        register its attributes registration callbacks with the node
>        driver, eliminating the dependency between the node driver
>        and hugetlbfs.  From it's init func, hugetlbfs will register
>        all on-line nodes' hugepage sysfs attributes along with
>        hugetlbfs' attributes register/unregister functions.  The
>        node driver will use these functions to [un]register nodes
>        with hugetlbfs on node hot-plug.
>      + replaced hugetlb.c private "nodes_allowed_from_node()" with
>        [new] generic "alloc_nodemask_of_node()".
> 
> V5a: + fix !NUMA register_hugetlbfs_with_node():  don't use
>        keyword 'do' as parameter name!
> 
> This patch adds the per huge page size control/query attributes
> to the per node sysdevs:
> 
> /sys/devices/system/node/node<ID>/hugepages/hugepages-<size>/
> 	nr_hugepages       - r/w
> 	free_huge_pages    - r/o
> 	surplus_huge_pages - r/o
> 
> The patch attempts to re-use/share as much of the existing
> global hstate attribute initialization and handling, and the
> "nodes_allowed" constraint processing as possible.
> Calling set_max_huge_pages() with no node indicates a change to
> global hstate parameters.  In this case, any non-default task
> mempolicy will be used to generate the nodes_allowed mask.  A
> valid node id indicates an update to that node's hstate 
> parameters, and the count argument specifies the target count
> for the specified node.  From this info, we compute the target
> global count for the hstate and construct a nodes_allowed node
> mask contain only the specified node.
> 
> Setting the node specific nr_hugepages via the per node attribute
> effectively ignores any task mempolicy or cpuset constraints.
> 
> With this patch:
> 
> (me):ls /sys/devices/system/node/node0/hugepages/hugepages-2048kB
> ./  ../  free_hugepages  nr_hugepages  surplus_hugepages
> 
> Starting from:
> Node 0 HugePages_Total:     0
> Node 0 HugePages_Free:      0
> Node 0 HugePages_Surp:      0
> Node 1 HugePages_Total:     0
> Node 1 HugePages_Free:      0
> Node 1 HugePages_Surp:      0
> Node 2 HugePages_Total:     0
> Node 2 HugePages_Free:      0
> Node 2 HugePages_Surp:      0
> Node 3 HugePages_Total:     0
> Node 3 HugePages_Free:      0
> Node 3 HugePages_Surp:      0
> vm.nr_hugepages = 0
> 
> Allocate 16 persistent huge pages on node 2:
> (me):echo 16 >/sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages
> 
> [Note that this is equivalent to:
> 	numactl -m 2 hugeadmin --pool-pages-min 2M:+16
> ]
> 
> Yields:
> Node 0 HugePages_Total:     0
> Node 0 HugePages_Free:      0
> Node 0 HugePages_Surp:      0
> Node 1 HugePages_Total:     0
> Node 1 HugePages_Free:      0
> Node 1 HugePages_Surp:      0
> Node 2 HugePages_Total:    16
> Node 2 HugePages_Free:     16
> Node 2 HugePages_Surp:      0
> Node 3 HugePages_Total:     0
> Node 3 HugePages_Free:      0
> Node 3 HugePages_Surp:      0
> vm.nr_hugepages = 16
> 
> Global controls work as expected--reduce pool to 8 persistent huge pages:
> (me):echo 8 >/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
> 
> Node 0 HugePages_Total:     0
> Node 0 HugePages_Free:      0
> Node 0 HugePages_Surp:      0
> Node 1 HugePages_Total:     0
> Node 1 HugePages_Free:      0
> Node 1 HugePages_Surp:      0
> Node 2 HugePages_Total:     8
> Node 2 HugePages_Free:      8
> Node 2 HugePages_Surp:      0
> Node 3 HugePages_Total:     0
> Node 3 HugePages_Free:      0
> Node 3 HugePages_Surp:      0
> 
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 

Ok, this appears to be acting as advertised as well. It also builds and
boots on !NUMA which is something it tripped over before. The dependencies
between base NUMA support and hugetlbfs are still looking reasonable to my
eye and you've cleaned up the magic numbers I was whinging about the last time.

Basically I have no problem with it even though I still think that
memory policies were sufficient. I'm going to chicken out and leave it
up to David Rientjes but from me

Acked-by: Mel Gorman <mel@csn.ul.ie>

>  drivers/base/node.c  |   33 ++++++
>  include/linux/node.h |    8 +
>  include/linux/numa.h |    2 
>  mm/hugetlb.c         |  245 ++++++++++++++++++++++++++++++++++++++++++++-------
>  4 files changed, 258 insertions(+), 30 deletions(-)
> 
> Index: linux-2.6.31-rc7-mmotm-090827-0057/drivers/base/node.c
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/drivers/base/node.c	2009-08-28 09:21:17.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/drivers/base/node.c	2009-08-28 09:21:31.000000000 -0400
> @@ -177,6 +177,37 @@ static ssize_t node_read_distance(struct
>  }
>  static SYSDEV_ATTR(distance, S_IRUGO, node_read_distance, NULL);
>  
> +/*
> + * hugetlbfs per node attributes registration interface:
> + * When/if hugetlb[fs] subsystem initializes [sometime after this module],
> + * it will register it's per node attributes for all nodes on-line at that
> + * point.  It will also call register_hugetlbfs_with_node(), below, to
> + * register it's attribute registration functions with this node driver.
> + * Once these hooks have been initialized, the node driver will call into
> + * the hugetlb module to [un]register attributes for hot-plugged nodes.
> + */
> +NODE_REGISTRATION_FUNC __hugetlb_register_node;
> +NODE_REGISTRATION_FUNC __hugetlb_unregister_node;
> +
> +static inline void hugetlb_register_node(struct node *node)
> +{
> +	if (__hugetlb_register_node)
> +		__hugetlb_register_node(node);
> +}
> +
> +static inline void hugetlb_unregister_node(struct node *node)
> +{
> +	if (__hugetlb_unregister_node)
> +		__hugetlb_unregister_node(node);
> +}
> +
> +void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC doregister,
> +                                  NODE_REGISTRATION_FUNC unregister)
> +{
> +	__hugetlb_register_node   = doregister;
> +	__hugetlb_unregister_node = unregister;
> +}
> +
>  
>  /*
>   * register_node - Setup a sysfs device for a node.
> @@ -200,6 +231,7 @@ int register_node(struct node *node, int
>  		sysdev_create_file(&node->sysdev, &attr_distance);
>  
>  		scan_unevictable_register_node(node);
> +		hugetlb_register_node(node);
>  	}
>  	return error;
>  }
> @@ -220,6 +252,7 @@ void unregister_node(struct node *node)
>  	sysdev_remove_file(&node->sysdev, &attr_distance);
>  
>  	scan_unevictable_unregister_node(node);
> +	hugetlb_unregister_node(node);
>  
>  	sysdev_unregister(&node->sysdev);
>  }
> Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:31.000000000 -0400
> @@ -24,6 +24,7 @@
>  #include <asm/io.h>
>  
>  #include <linux/hugetlb.h>
> +#include <linux/node.h>
>  #include "internal.h"
>  
>  const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
> @@ -1245,7 +1246,8 @@ static int adjust_pool_surplus(struct hs
>  }
>  
>  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> -static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
> +static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> +								int nid)
>  {
>  	unsigned long min_count, ret;
>  	nodemask_t *nodes_allowed;
> @@ -1253,7 +1255,21 @@ static unsigned long set_max_huge_pages(
>  	if (h->order >= MAX_ORDER)
>  		return h->max_huge_pages;
>  
> -	nodes_allowed = huge_mpol_nodes_allowed();
> +	if (nid == NO_NODEID_SPECIFIED)
> +		nodes_allowed = huge_mpol_nodes_allowed();
> +	else {
> +		/*
> +		 * incoming 'count' is for node 'nid' only, so
> +		 * adjust count to global, but restrict alloc/free
> +		 * to the specified node.
> +		 */
> +		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
> +		nodes_allowed = alloc_nodemask_of_node(nid);
> +		if (!nodes_allowed)
> +			printk(KERN_WARNING "%s unable to allocate allowed "
> +			       "nodes mask for huge page allocation/free.  "
> +			       "Falling back to default.\n", current->comm);
> +	}
>  
>  	/*
>  	 * Increase the pool size
> @@ -1329,51 +1345,71 @@ out:
>  static struct kobject *hugepages_kobj;
>  static struct kobject *hstate_kobjs[HUGE_MAX_HSTATE];
>  
> -static struct hstate *kobj_to_hstate(struct kobject *kobj)
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp);
> +
> +static struct hstate *kobj_to_hstate(struct kobject *kobj, int *nidp)
>  {
>  	int i;
> +
>  	for (i = 0; i < HUGE_MAX_HSTATE; i++)
> -		if (hstate_kobjs[i] == kobj)
> +		if (hstate_kobjs[i] == kobj) {
> +			if (nidp)
> +				*nidp = NO_NODEID_SPECIFIED;
>  			return &hstates[i];
> -	BUG();
> -	return NULL;
> +		}
> +
> +	return kobj_to_node_hstate(kobj, nidp);
>  }
>  
>  static ssize_t nr_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->nr_huge_pages);
> +	struct hstate *h;
> +	unsigned long nr_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		nr_huge_pages = h->nr_huge_pages;
> +	else
> +		nr_huge_pages = h->nr_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", nr_huge_pages);
>  }
> +
>  static ssize_t nr_hugepages_store(struct kobject *kobj,
> -		struct kobj_attribute *attr, const char *buf, size_t count)
> +		struct kobj_attribute *attr, const char *buf, size_t len)
>  {
> +	unsigned long count;
> +	struct hstate *h;
> +	int nid;
>  	int err;
> -	unsigned long input;
> -	struct hstate *h = kobj_to_hstate(kobj);
>  
> -	err = strict_strtoul(buf, 10, &input);
> +	err = strict_strtoul(buf, 10, &count);
>  	if (err)
>  		return 0;
>  
> -	h->max_huge_pages = set_max_huge_pages(h, input);
> +	h = kobj_to_hstate(kobj, &nid);
> +	h->max_huge_pages = set_max_huge_pages(h, count, nid);
>  
> -	return count;
> +	return len;
>  }
>  HSTATE_ATTR(nr_hugepages);
>  
>  static ssize_t nr_overcommit_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> +
>  	return sprintf(buf, "%lu\n", h->nr_overcommit_huge_pages);
>  }
> +
>  static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
>  		struct kobj_attribute *attr, const char *buf, size_t count)
>  {
>  	int err;
>  	unsigned long input;
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
>  
>  	err = strict_strtoul(buf, 10, &input);
>  	if (err)
> @@ -1390,15 +1426,24 @@ HSTATE_ATTR(nr_overcommit_hugepages);
>  static ssize_t free_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->free_huge_pages);
> +	struct hstate *h;
> +	unsigned long free_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		free_huge_pages = h->free_huge_pages;
> +	else
> +		free_huge_pages = h->free_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", free_huge_pages);
>  }
>  HSTATE_ATTR_RO(free_hugepages);
>  
>  static ssize_t resv_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
>  	return sprintf(buf, "%lu\n", h->resv_huge_pages);
>  }
>  HSTATE_ATTR_RO(resv_hugepages);
> @@ -1406,8 +1451,17 @@ HSTATE_ATTR_RO(resv_hugepages);
>  static ssize_t surplus_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->surplus_huge_pages);
> +	struct hstate *h;
> +	unsigned long surplus_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		surplus_huge_pages = h->surplus_huge_pages;
> +	else
> +		surplus_huge_pages = h->surplus_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", surplus_huge_pages);
>  }
>  HSTATE_ATTR_RO(surplus_hugepages);
>  
> @@ -1424,19 +1478,21 @@ static struct attribute_group hstate_att
>  	.attrs = hstate_attrs,
>  };
>  
> -static int __init hugetlb_sysfs_add_hstate(struct hstate *h)
> +static int __init hugetlb_sysfs_add_hstate(struct hstate *h,
> +				struct kobject *parent,
> +				struct kobject **hstate_kobjs,
> +				struct attribute_group *hstate_attr_group)
>  {
>  	int retval;
> +	int hi = h - hstates;
>  
> -	hstate_kobjs[h - hstates] = kobject_create_and_add(h->name,
> -							hugepages_kobj);
> -	if (!hstate_kobjs[h - hstates])
> +	hstate_kobjs[hi] = kobject_create_and_add(h->name, parent);
> +	if (!hstate_kobjs[hi])
>  		return -ENOMEM;
>  
> -	retval = sysfs_create_group(hstate_kobjs[h - hstates],
> -							&hstate_attr_group);
> +	retval = sysfs_create_group(hstate_kobjs[hi], hstate_attr_group);
>  	if (retval)
> -		kobject_put(hstate_kobjs[h - hstates]);
> +		kobject_put(hstate_kobjs[hi]);
>  
>  	return retval;
>  }
> @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
>  		return;
>  
>  	for_each_hstate(h) {
> -		err = hugetlb_sysfs_add_hstate(h);
> +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> +					 hstate_kobjs, &hstate_attr_group);
>  		if (err)
>  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
>  								h->name);
>  	}
>  }
>  
> +#ifdef CONFIG_NUMA
> +
> +struct node_hstate {
> +	struct kobject		*hugepages_kobj;
> +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> +};
> +struct node_hstate node_hstates[MAX_NUMNODES];
> +
> +static struct attribute *per_node_hstate_attrs[] = {
> +	&nr_hugepages_attr.attr,
> +	&free_hugepages_attr.attr,
> +	&surplus_hugepages_attr.attr,
> +	NULL,
> +};
> +
> +static struct attribute_group per_node_hstate_attr_group = {
> +	.attrs = per_node_hstate_attrs,
> +};
> +
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++) {
> +		struct node_hstate *nhs = &node_hstates[nid];
> +		int i;
> +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> +			if (nhs->hstate_kobjs[i] == kobj) {
> +				if (nidp)
> +					*nidp = nid;
> +				return &hstates[i];
> +			}
> +	}
> +
> +	BUG();
> +	return NULL;
> +}
> +
> +void hugetlb_unregister_node(struct node *node)
> +{
> +	struct hstate *h;
> +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> +
> +	if (!nhs->hugepages_kobj)
> +		return;
> +
> +	for_each_hstate(h)
> +		if (nhs->hstate_kobjs[h - hstates]) {
> +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> +			nhs->hstate_kobjs[h - hstates] = NULL;
> +		}
> +
> +	kobject_put(nhs->hugepages_kobj);
> +	nhs->hugepages_kobj = NULL;
> +}
> +
> +static void hugetlb_unregister_all_nodes(void)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++)
> +		hugetlb_unregister_node(&node_devices[nid]);
> +
> +	register_hugetlbfs_with_node(NULL, NULL);
> +}
> +
> +void hugetlb_register_node(struct node *node)
> +{
> +	struct hstate *h;
> +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> +	int err;
> +
> +	if (nhs->hugepages_kobj)
> +		return;		/* already allocated */
> +
> +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> +							&node->sysdev.kobj);
> +	if (!nhs->hugepages_kobj)
> +		return;
> +
> +	for_each_hstate(h) {
> +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> +						nhs->hstate_kobjs,
> +						&per_node_hstate_attr_group);
> +		if (err) {
> +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> +					" for node %d\n",
> +						h->name, node->sysdev.id);
> +			hugetlb_unregister_node(node);
> +			break;
> +		}
> +	}
> +}
> +
> +static void hugetlb_register_all_nodes(void)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++) {
> +		struct node *node = &node_devices[nid];
> +		if (node->sysdev.id == nid)
> +			hugetlb_register_node(node);
> +	}
> +
> +	register_hugetlbfs_with_node(hugetlb_register_node,
> +                                     hugetlb_unregister_node);
> +}
> +#else	/* !CONFIG_NUMA */
> +
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> +{
> +	BUG();
> +	if (nidp)
> +		*nidp = -1;
> +	return NULL;
> +}
> +
> +static void hugetlb_unregister_all_nodes(void) { }
> +
> +static void hugetlb_register_all_nodes(void) { }
> +
> +#endif
> +
>  static void __exit hugetlb_exit(void)
>  {
>  	struct hstate *h;
>  
> +	hugetlb_unregister_all_nodes();
> +
>  	for_each_hstate(h) {
>  		kobject_put(hstate_kobjs[h - hstates]);
>  	}
> @@ -1496,6 +1678,8 @@ static int __init hugetlb_init(void)
>  
>  	hugetlb_sysfs_init();
>  
> +	hugetlb_register_all_nodes();
> +
>  	return 0;
>  }
>  module_init(hugetlb_init);
> @@ -1598,7 +1782,8 @@ int hugetlb_sysctl_handler(struct ctl_ta
>  	proc_doulongvec_minmax(table, write, buffer, length, ppos);
>  
>  	if (write)
> -		h->max_huge_pages = set_max_huge_pages(h, tmp);
> +		h->max_huge_pages = set_max_huge_pages(h, tmp,
> +		                                       NO_NODEID_SPECIFIED);
>  
>  	return 0;
>  }
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
> @@ -10,4 +10,6 @@
>  
>  #define MAX_NUMNODES    (1 << NODES_SHIFT)
>  
> +#define NO_NODEID_SPECIFIED	(-1)
> +
>  #endif /* _LINUX_NUMA_H */
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/node.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/node.h	2009-08-28 09:21:17.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/node.h	2009-08-28 09:21:31.000000000 -0400
> @@ -28,6 +28,7 @@ struct node {
>  
>  struct memory_block;
>  extern struct node node_devices[];
> +typedef  void (*NODE_REGISTRATION_FUNC)(struct node *);
>  
>  extern int register_node(struct node *, int, struct node *);
>  extern void unregister_node(struct node *node);
> @@ -39,6 +40,8 @@ extern int unregister_cpu_under_node(uns
>  extern int register_mem_sect_under_node(struct memory_block *mem_blk,
>  						int nid);
>  extern int unregister_mem_sect_under_nodes(struct memory_block *mem_blk);
> +extern void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC doregister,
> +                                         NODE_REGISTRATION_FUNC unregister);
>  #else
>  static inline int register_one_node(int nid)
>  {
> @@ -65,6 +68,11 @@ static inline int unregister_mem_sect_un
>  {
>  	return 0;
>  }
> +
> +static inline void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC reg,
> +                                                NODE_REGISTRATION_FUNC unreg)
> +{
> +}
>  #endif
>  
>  #define to_node(sys_device) container_of(sys_device, struct node, sysdev)
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51])
	by kanga.kvack.org (Postfix) with ESMTP id 09D136B004F
	for <linux-mm@kvack.org>; Tue,  1 Sep 2009 12:42:14 -0400 (EDT)
Subject: Re: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
In-Reply-To: <20090901144932.GB7548@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160338.11080.51282.sendpatchset@localhost.localdomain>
	 <20090901144932.GB7548@csn.ul.ie>
Content-Type: text/plain
Date: Tue, 01 Sep 2009 12:42:14 -0400
Message-Id: <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Tue, 2009-09-01 at 15:49 +0100, Mel Gorman wrote:
> On Fri, Aug 28, 2009 at 12:03:38PM -0400, Lee Schermerhorn wrote:
> > [PATCH 4/6] - hugetlb:  introduce alloc_nodemask_of_node()
> > 
> > Against:  2.6.31-rc7-mmotm-090827-0057
> > 
> > New in V5 of series
> > 
> > Introduce nodemask macro to allocate a nodemask and 
> > initialize it to contain a single node, using the macro
> > init_nodemask_of_node() factored out of the nodemask_of_node()
> > macro.
> > 
> > alloc_nodemask_of_node() coded as a macro to avoid header
> > dependency hell.
> > 
> > This will be used to construct the huge pages "nodes_allowed"
> > nodemask for a single node when a persistent huge page
> > pool page count is modified via a per node sysfs attribute.
> > 
> > Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> > 
> >  include/linux/nodemask.h |   20 ++++++++++++++++++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
> > ===================================================================
> > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h	2009-08-28 09:21:19.000000000 -0400
> > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h	2009-08-28 09:21:29.000000000 -0400
> > @@ -245,18 +245,34 @@ static inline int __next_node(int n, con
> >  	return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
> >  }
> >  
> > +#define init_nodemask_of_nodes(mask, node)				\
> > +	nodes_clear(*(mask));						\
> > +	node_set((node), *(mask));
> > +
> 
> Is the done thing to either make this a static inline or else wrap it in
> a do { } while(0) ? The reasoning being that if this is used as part of an
> another statement (e.g. a for loop) that it'll actually compile instead of
> throw up weird error messages.

Right.  I'll fix this [and signoff/review orders] next time [maybe last
time?].  It occurs to me that I can also use this for
huge_mpol_nodes_allowed(), so I'll move it up in the series and fix that
[which you've already ack'd].  I'll wait a bit to hear from David before
I respin.

Thanks,
Lee
> 
> >  #define nodemask_of_node(node)						\
> >  ({									\
> >  	typeof(_unused_nodemask_arg_) m;				\
> >  	if (sizeof(m) == sizeof(unsigned long)) {			\
> >  		m.bits[0] = 1UL<<(node);				\
> >  	} else {							\
> > -		nodes_clear(m);						\
> > -		node_set((node), m);					\
> > +		init_nodemask_of_nodes(&m, (node));			\
> >  	}								\
> >  	m;								\
> >  })
> >  
> > +/*
> > + * returns pointer to kmalloc()'d nodemask initialized to contain the
> > + * specified node.  Caller must free with kfree().
> > + */
> > +#define alloc_nodemask_of_node(node)					\
> > +({									\
> > +	typeof(_unused_nodemask_arg_) *nmp;				\
> > +	nmp = kmalloc(sizeof(*nmp), GFP_KERNEL);			\
> > +	if (nmp)							\
> > +		init_nodemask_of_nodes(nmp, (node));			\
> > +	nmp;								\
> > +})
> > +
> 
> Otherwise, it looks ok.
> 
> >  #define first_unset_node(mask) __first_unset_node(&(mask))
> >  static inline int __first_unset_node(const nodemask_t *maskp)
> >  {
> > 
> 

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35])
	by kanga.kvack.org (Postfix) with ESMTP id ECAA56B005A
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 14:34:34 -0400 (EDT)
Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35])
	by smtp-out.google.com with ESMTP id n83IYTLd013625
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 19:34:30 +0100
Received: from pxi27 (pxi27.prod.google.com [10.243.27.27])
	by zps35.corp.google.com with ESMTP id n83IYLdN015054
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 11:34:27 -0700
Received: by pxi27 with SMTP id 27so116363pxi.15
        for <linux-mm@kvack.org>; Thu, 03 Sep 2009 11:34:26 -0700 (PDT)
Date: Thu, 3 Sep 2009 11:34:24 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
In-Reply-To: <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
Message-ID: <alpine.DEB.1.00.0909031122590.9055@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160338.11080.51282.sendpatchset@localhost.localdomain> <20090901144932.GB7548@csn.ul.ie> <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Tue, 1 Sep 2009, Lee Schermerhorn wrote:

> > > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
> > > ===================================================================
> > > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h	2009-08-28 09:21:19.000000000 -0400
> > > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h	2009-08-28 09:21:29.000000000 -0400
> > > @@ -245,18 +245,34 @@ static inline int __next_node(int n, con
> > >  	return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
> > >  }
> > >  
> > > +#define init_nodemask_of_nodes(mask, node)				\
> > > +	nodes_clear(*(mask));						\
> > > +	node_set((node), *(mask));
> > > +
> > 
> > Is the done thing to either make this a static inline or else wrap it in
> > a do { } while(0) ? The reasoning being that if this is used as part of an
> > another statement (e.g. a for loop) that it'll actually compile instead of
> > throw up weird error messages.
> 
> Right.  I'll fix this [and signoff/review orders] next time [maybe last
> time?].  It occurs to me that I can also use this for
> huge_mpol_nodes_allowed(), so I'll move it up in the series and fix that
> [which you've already ack'd].  I'll wait a bit to hear from David before
> I respin.
> 

I think it should be an inline function just so there's typechecking on 
the first argument passed in (and so alloc_nodemask_of_node() below 
doesn't get a NULL pointer dereference on node_set() if nmp can't be 
allocated).

I've seen the issue about the signed-off-by/reviewed-by/acked-by order 
come up before.  I've always put my signed-off-by line last whenever 
proposing patches because it shows a clear order in who gathered those 
lines when submitting to -mm, for example.  If I write

	Cc: Mel Gorman <mel@csn.ul.ie>
	Signed-off-by: David Rientjes <rientjes@google.com>

it is clear that I cc'd Mel on the initial proposal.  If it is the other 
way around, for example,

	Signed-off-by: David Rientjes <rientjes@google.com>
	Cc: Mel Gorman <mel@csn.ul.ie>
	Signed-off-by: Andrew Morton...

then it indicates Andrew added the cc when merging into -mm.  That's more 
relevant when such a line is acked-by or reviewed-by since it is now 
possible to determine who received such acknowledgement from the 
individual and is responsible for correctly relaying it in the patch 
submission.

If it's done this way, it indicates that whoever is signing off the patch 
is responsible for everything above it.  The type of line (signed-off-by, 
reviewed-by, acked-by) is enough of an indication about the development 
history of the patch, I believe, and it doesn't require specific ordering 
to communicate (and the first line having to be a signed-off-by line isn't 
really important, it doesn't replace the From: line).

It also appears to be how both Linus merges his own patches with Cc's.

> > > +/*
> > > + * returns pointer to kmalloc()'d nodemask initialized to contain the
> > > + * specified node.  Caller must free with kfree().
> > > + */
> > > +#define alloc_nodemask_of_node(node)					\
> > > +({									\
> > > +	typeof(_unused_nodemask_arg_) *nmp;				\
> > > +	nmp = kmalloc(sizeof(*nmp), GFP_KERNEL);			\
> > > +	if (nmp)							\
> > > +		init_nodemask_of_nodes(nmp, (node));			\
> > > +	nmp;								\
> > > +})
> > > +
> > 

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19])
	by kanga.kvack.org (Postfix) with ESMTP id EACAC6B005D
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 14:39:43 -0400 (EDT)
Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37])
	by smtp-out.google.com with ESMTP id n83Idhgp004847
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 11:39:43 -0700
Received: from pxi42 (pxi42.prod.google.com [10.243.27.42])
	by zps37.corp.google.com with ESMTP id n83IcSTf023861
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 11:39:41 -0700
Received: by pxi42 with SMTP id 42so125278pxi.20
        for <linux-mm@kvack.org>; Thu, 03 Sep 2009 11:39:41 -0700 (PDT)
Date: Thu, 3 Sep 2009 11:39:39 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 2/6] hugetlb:  add nodemask arg to huge page alloc, free
 and surplus adjust fcns
In-Reply-To: <20090828160326.11080.56814.sendpatchset@localhost.localdomain>
Message-ID: <alpine.DEB.1.00.0909031138010.9055@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160326.11080.56814.sendpatchset@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Fri, 28 Aug 2009, Lee Schermerhorn wrote:

> [PATCH 2/6] hugetlb:  add nodemask arg to huge page alloc, free and surplus adjust fcns
> 
> Against:  2.6.31-rc7-mmotm-090827-0057
> 
> V3:
> + moved this patch to after the "rework" of hstate_next_node_to_...
>   functions as this patch is more specific to using task mempolicy
>   to control huge page allocation and freeing.
> 
> V5:
> + removed now unneeded 'nextnid' from hstate_next_node_to_{alloc|free}
>   and updated the stale comments.
> 
> In preparation for constraining huge page allocation and freeing by the
> controlling task's numa mempolicy, add a "nodes_allowed" nodemask pointer
> to the allocate, free and surplus adjustment functions.  For now, pass
> NULL to indicate default behavior--i.e., use node_online_map.  A
> subsqeuent patch will derive a non-default mask from the controlling 
> task's numa mempolicy.
> 
> Note that this method of updating the global hstate nr_hugepages under
> the constraint of a nodemask simplifies keeping the global state 
> consistent--especially the number of persistent and surplus pages
> relative to reservations and overcommit limits.  There are undoubtedly
> other ways to do this, but this works for both interfaces:  mempolicy
> and per node attributes.
> 
> Reviewed-by: Mel Gorman <mel@csn.ul.ie>
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

Still think the name `this_node_allowed()' is awkward, but I'm glad to see 
hstate_next_node_to_{alloc,free} is clean.

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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35])
	by kanga.kvack.org (Postfix) with ESMTP id CB7AD6B004F
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 15:22:15 -0400 (EDT)
Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75])
	by smtp-out.google.com with ESMTP id n83JMJph032324
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 20:22:20 +0100
Received: from pzk39 (pzk39.prod.google.com [10.243.19.167])
	by zps75.corp.google.com with ESMTP id n83JMGLO017250
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 12:22:17 -0700
Received: by pzk39 with SMTP id 39so147825pzk.15
        for <linux-mm@kvack.org>; Thu, 03 Sep 2009 12:22:16 -0700 (PDT)
Date: Thu, 3 Sep 2009 12:22:13 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from task
 mempolicy
In-Reply-To: <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
Message-ID: <alpine.DEB.1.00.0909031212110.22173@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with ESMTP id 2D9A66B005C
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 15:52:42 -0400 (EDT)
Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93])
	by smtp-out.google.com with ESMTP id n83JqiOg003157
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 20:52:44 +0100
Received: from pzk26 (pzk26.prod.google.com [10.243.19.154])
	by wpaz29.hot.corp.google.com with ESMTP id n83Jqf0a016010
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 12:52:41 -0700
Received: by pzk26 with SMTP id 26so159305pzk.0
        for <linux-mm@kvack.org>; Thu, 03 Sep 2009 12:52:41 -0700 (PDT)
Date: Thu, 3 Sep 2009 12:52:37 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
In-Reply-To: <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
Message-ID: <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Fri, 28 Aug 2009, Lee Schermerhorn wrote:

> Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:31.000000000 -0400
> @@ -24,6 +24,7 @@
>  #include <asm/io.h>
>  
>  #include <linux/hugetlb.h>
> +#include <linux/node.h>
>  #include "internal.h"
>  
>  const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
> @@ -1245,7 +1246,8 @@ static int adjust_pool_surplus(struct hs
>  }
>  
>  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> -static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
> +static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> +								int nid)
>  {
>  	unsigned long min_count, ret;
>  	nodemask_t *nodes_allowed;
> @@ -1253,7 +1255,21 @@ static unsigned long set_max_huge_pages(
>  	if (h->order >= MAX_ORDER)
>  		return h->max_huge_pages;
>  
> -	nodes_allowed = huge_mpol_nodes_allowed();
> +	if (nid == NO_NODEID_SPECIFIED)
> +		nodes_allowed = huge_mpol_nodes_allowed();
> +	else {
> +		/*
> +		 * incoming 'count' is for node 'nid' only, so
> +		 * adjust count to global, but restrict alloc/free
> +		 * to the specified node.
> +		 */
> +		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
> +		nodes_allowed = alloc_nodemask_of_node(nid);
> +		if (!nodes_allowed)
> +			printk(KERN_WARNING "%s unable to allocate allowed "
> +			       "nodes mask for huge page allocation/free.  "
> +			       "Falling back to default.\n", current->comm);
> +	}
>  
>  	/*
>  	 * Increase the pool size
> @@ -1329,51 +1345,71 @@ out:
>  static struct kobject *hugepages_kobj;
>  static struct kobject *hstate_kobjs[HUGE_MAX_HSTATE];
>  
> -static struct hstate *kobj_to_hstate(struct kobject *kobj)
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp);
> +
> +static struct hstate *kobj_to_hstate(struct kobject *kobj, int *nidp)
>  {
>  	int i;
> +
>  	for (i = 0; i < HUGE_MAX_HSTATE; i++)
> -		if (hstate_kobjs[i] == kobj)
> +		if (hstate_kobjs[i] == kobj) {
> +			if (nidp)
> +				*nidp = NO_NODEID_SPECIFIED;
>  			return &hstates[i];
> -	BUG();
> -	return NULL;
> +		}
> +
> +	return kobj_to_node_hstate(kobj, nidp);
>  }
>  
>  static ssize_t nr_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->nr_huge_pages);
> +	struct hstate *h;
> +	unsigned long nr_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		nr_huge_pages = h->nr_huge_pages;
> +	else
> +		nr_huge_pages = h->nr_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", nr_huge_pages);
>  }
> +
>  static ssize_t nr_hugepages_store(struct kobject *kobj,
> -		struct kobj_attribute *attr, const char *buf, size_t count)
> +		struct kobj_attribute *attr, const char *buf, size_t len)
>  {
> +	unsigned long count;
> +	struct hstate *h;
> +	int nid;
>  	int err;
> -	unsigned long input;
> -	struct hstate *h = kobj_to_hstate(kobj);
>  
> -	err = strict_strtoul(buf, 10, &input);
> +	err = strict_strtoul(buf, 10, &count);
>  	if (err)
>  		return 0;
>  
> -	h->max_huge_pages = set_max_huge_pages(h, input);
> +	h = kobj_to_hstate(kobj, &nid);
> +	h->max_huge_pages = set_max_huge_pages(h, count, nid);
>  
> -	return count;
> +	return len;
>  }
>  HSTATE_ATTR(nr_hugepages);
>  
>  static ssize_t nr_overcommit_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> +
>  	return sprintf(buf, "%lu\n", h->nr_overcommit_huge_pages);
>  }
> +
>  static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
>  		struct kobj_attribute *attr, const char *buf, size_t count)
>  {
>  	int err;
>  	unsigned long input;
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
>  
>  	err = strict_strtoul(buf, 10, &input);
>  	if (err)
> @@ -1390,15 +1426,24 @@ HSTATE_ATTR(nr_overcommit_hugepages);
>  static ssize_t free_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->free_huge_pages);
> +	struct hstate *h;
> +	unsigned long free_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		free_huge_pages = h->free_huge_pages;
> +	else
> +		free_huge_pages = h->free_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", free_huge_pages);
>  }
>  HSTATE_ATTR_RO(free_hugepages);
>  
>  static ssize_t resv_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
>  	return sprintf(buf, "%lu\n", h->resv_huge_pages);
>  }
>  HSTATE_ATTR_RO(resv_hugepages);
> @@ -1406,8 +1451,17 @@ HSTATE_ATTR_RO(resv_hugepages);
>  static ssize_t surplus_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->surplus_huge_pages);
> +	struct hstate *h;
> +	unsigned long surplus_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		surplus_huge_pages = h->surplus_huge_pages;
> +	else
> +		surplus_huge_pages = h->surplus_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", surplus_huge_pages);
>  }
>  HSTATE_ATTR_RO(surplus_hugepages);
>  
> @@ -1424,19 +1478,21 @@ static struct attribute_group hstate_att
>  	.attrs = hstate_attrs,
>  };
>  
> -static int __init hugetlb_sysfs_add_hstate(struct hstate *h)
> +static int __init hugetlb_sysfs_add_hstate(struct hstate *h,
> +				struct kobject *parent,
> +				struct kobject **hstate_kobjs,
> +				struct attribute_group *hstate_attr_group)
>  {
>  	int retval;
> +	int hi = h - hstates;
>  
> -	hstate_kobjs[h - hstates] = kobject_create_and_add(h->name,
> -							hugepages_kobj);
> -	if (!hstate_kobjs[h - hstates])
> +	hstate_kobjs[hi] = kobject_create_and_add(h->name, parent);
> +	if (!hstate_kobjs[hi])
>  		return -ENOMEM;
>  
> -	retval = sysfs_create_group(hstate_kobjs[h - hstates],
> -							&hstate_attr_group);
> +	retval = sysfs_create_group(hstate_kobjs[hi], hstate_attr_group);
>  	if (retval)
> -		kobject_put(hstate_kobjs[h - hstates]);
> +		kobject_put(hstate_kobjs[hi]);
>  
>  	return retval;
>  }
> @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
>  		return;
>  
>  	for_each_hstate(h) {
> -		err = hugetlb_sysfs_add_hstate(h);
> +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> +					 hstate_kobjs, &hstate_attr_group);
>  		if (err)
>  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
>  								h->name);
>  	}
>  }
>  
> +#ifdef CONFIG_NUMA
> +
> +struct node_hstate {
> +	struct kobject		*hugepages_kobj;
> +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> +};
> +struct node_hstate node_hstates[MAX_NUMNODES];
> +
> +static struct attribute *per_node_hstate_attrs[] = {
> +	&nr_hugepages_attr.attr,
> +	&free_hugepages_attr.attr,
> +	&surplus_hugepages_attr.attr,
> +	NULL,
> +};
> +
> +static struct attribute_group per_node_hstate_attr_group = {
> +	.attrs = per_node_hstate_attrs,
> +};
> +
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++) {
> +		struct node_hstate *nhs = &node_hstates[nid];
> +		int i;
> +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> +			if (nhs->hstate_kobjs[i] == kobj) {
> +				if (nidp)
> +					*nidp = nid;
> +				return &hstates[i];
> +			}
> +	}
> +
> +	BUG();
> +	return NULL;
> +}
> +
> +void hugetlb_unregister_node(struct node *node)
> +{
> +	struct hstate *h;
> +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> +
> +	if (!nhs->hugepages_kobj)
> +		return;
> +
> +	for_each_hstate(h)
> +		if (nhs->hstate_kobjs[h - hstates]) {
> +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> +			nhs->hstate_kobjs[h - hstates] = NULL;
> +		}
> +
> +	kobject_put(nhs->hugepages_kobj);
> +	nhs->hugepages_kobj = NULL;
> +}
> +
> +static void hugetlb_unregister_all_nodes(void)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++)
> +		hugetlb_unregister_node(&node_devices[nid]);
> +
> +	register_hugetlbfs_with_node(NULL, NULL);
> +}
> +
> +void hugetlb_register_node(struct node *node)
> +{
> +	struct hstate *h;
> +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> +	int err;
> +
> +	if (nhs->hugepages_kobj)
> +		return;		/* already allocated */
> +
> +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> +							&node->sysdev.kobj);
> +	if (!nhs->hugepages_kobj)
> +		return;
> +
> +	for_each_hstate(h) {
> +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> +						nhs->hstate_kobjs,
> +						&per_node_hstate_attr_group);
> +		if (err) {
> +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> +					" for node %d\n",
> +						h->name, node->sysdev.id);

Maybe add `err' to the printk so we know whether it was an -ENOMEM 
condition or sysfs problem?

> +			hugetlb_unregister_node(node);
> +			break;
> +		}
> +	}
> +}
> +
> +static void hugetlb_register_all_nodes(void)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++) {

Don't you want to do this for all nodes in N_HIGH_MEMORY?  I don't think 
we should be adding attributes for memoryless nodes.

> +		struct node *node = &node_devices[nid];
> +		if (node->sysdev.id == nid)
> +			hugetlb_register_node(node);
> +	}
> +
> +	register_hugetlbfs_with_node(hugetlb_register_node,
> +                                     hugetlb_unregister_node);
> +}
> +#else	/* !CONFIG_NUMA */
> +
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> +{
> +	BUG();
> +	if (nidp)
> +		*nidp = -1;
> +	return NULL;
> +}
> +
> +static void hugetlb_unregister_all_nodes(void) { }
> +
> +static void hugetlb_register_all_nodes(void) { }
> +
> +#endif
> +
>  static void __exit hugetlb_exit(void)
>  {
>  	struct hstate *h;
>  
> +	hugetlb_unregister_all_nodes();
> +
>  	for_each_hstate(h) {
>  		kobject_put(hstate_kobjs[h - hstates]);
>  	}
> @@ -1496,6 +1678,8 @@ static int __init hugetlb_init(void)
>  
>  	hugetlb_sysfs_init();
>  
> +	hugetlb_register_all_nodes();
> +
>  	return 0;
>  }
>  module_init(hugetlb_init);
> @@ -1598,7 +1782,8 @@ int hugetlb_sysctl_handler(struct ctl_ta
>  	proc_doulongvec_minmax(table, write, buffer, length, ppos);
>  
>  	if (write)
> -		h->max_huge_pages = set_max_huge_pages(h, tmp);
> +		h->max_huge_pages = set_max_huge_pages(h, tmp,
> +		                                       NO_NODEID_SPECIFIED);
>  
>  	return 0;
>  }
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
> @@ -10,4 +10,6 @@
>  
>  #define MAX_NUMNODES    (1 << NODES_SHIFT)
>  
> +#define NO_NODEID_SPECIFIED	(-1)
> +
>  #endif /* _LINUX_NUMA_H */

Hmm, so we already have NUMA_NO_NODE in the ia64 and x86_64 code and 
NID_INVAL in the ACPI code, both of which are defined to -1.  Maybe rename 
your addition here in favor of NUMA_NO_NODE, remove it from the ia64 and 
x86 arch headers, and convert the ACPI code?

Thanks for doing this!

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3])
	by kanga.kvack.org (Postfix) with ESMTP id 23B086B005C
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 16:08:06 -0400 (EDT)
Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75])
	by smtp-out.google.com with ESMTP id n83K84LL010646
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 21:08:04 +0100
Received: from pxi12 (pxi12.prod.google.com [10.243.27.12])
	by spaceape23.eur.corp.google.com with ESMTP id n83K80Z4031810
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 13:08:01 -0700
Received: by pxi12 with SMTP id 12so81045pxi.0
        for <linux-mm@kvack.org>; Thu, 03 Sep 2009 13:08:00 -0700 (PDT)
Date: Thu, 3 Sep 2009 13:07:57 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
In-Reply-To: <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
Message-ID: <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Fri, 28 Aug 2009, Lee Schermerhorn wrote:

> [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy based management.
> 
> Against: 2.6.31-rc7-mmotm-090827-0057
> 
> V2:  Add brief description of per node attributes.
> 
> This patch updates the kernel huge tlb documentation to describe the
> numa memory policy based huge page management.  Additionaly, the patch
> includes a fair amount of rework to improve consistency, eliminate
> duplication and set the context for documenting the memory policy
> interaction.
> 
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

Adding Randy to the cc.  Comments below, but otherwise:

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

> 
>  Documentation/vm/hugetlbpage.txt |  257 ++++++++++++++++++++++++++-------------
>  1 file changed, 172 insertions(+), 85 deletions(-)
> 
> Index: linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:16.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:32.000000000 -0400
> @@ -11,23 +11,21 @@ This optimization is more critical now a
>  (several GBs) are more readily available.
>  
>  Users can use the huge page support in Linux kernel by either using the mmap
> -system call or standard SYSv shared memory system calls (shmget, shmat).
> +system call or standard SYSV shared memory system calls (shmget, shmat).
>  
>  First the Linux kernel needs to be built with the CONFIG_HUGETLBFS
>  (present under "File systems") and CONFIG_HUGETLB_PAGE (selected
>  automatically when CONFIG_HUGETLBFS is selected) configuration
>  options.
>  
> -The kernel built with huge page support should show the number of configured
> -huge pages in the system by running the "cat /proc/meminfo" command.
> +The /proc/meminfo file provides information about the total number of hugetlb
> +pages preallocated in the kernel's huge page pool.  It also displays
> +information about the number of free, reserved and surplus huge pages and the
> +[default] huge page size.  The huge page size is needed for generating the

Don't think the brackets are needed.

> +proper alignment and size of the arguments to system calls that map huge page
> +regions.
>  
> -/proc/meminfo also provides information about the total number of hugetlb
> -pages configured in the kernel.  It also displays information about the
> -number of free hugetlb pages at any time.  It also displays information about
> -the configured huge page size - this is needed for generating the proper
> -alignment and size of the arguments to the above system calls.
> -
> -The output of "cat /proc/meminfo" will have lines like:
> +The output of "cat /proc/meminfo" will include lines like:
>  
>  .....
>  HugePages_Total: vvv
> @@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
>  /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
>  in the kernel.
>  
> -/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
> -pages in the kernel.  Super user can dynamically request more (or free some
> -pre-configured) huge pages.
> -The allocation (or deallocation) of hugetlb pages is possible only if there are
> -enough physically contiguous free pages in system (freeing of huge pages is
> -possible only if there are enough hugetlb pages free that can be transferred
> -back to regular memory pool).
> -
> -Pages that are used as hugetlb pages are reserved inside the kernel and cannot
> -be used for other purposes.
> -
> -Once the kernel with Hugetlb page support is built and running, a user can
> -use either the mmap system call or shared memory system calls to start using
> -the huge pages.  It is required that the system administrator preallocate
> -enough memory for huge page purposes.
> -
> -The administrator can preallocate huge pages on the kernel boot command line by
> -specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
> -requested.  This is the most reliable method for preallocating huge pages as
> -memory has not yet become fragmented.
> +/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
> +allocated in the kernel's huge page pool.  These are called "persistent"
> +huge pages.  A user with root privileges can dynamically allocate more or
> +free some persistent huge pages by increasing or decreasing the value of
> +'nr_hugepages'.
> +

So they're not necessarily "preallocated" then if they're already in use.

> +Pages that are used as huge pages are reserved inside the kernel and cannot
> +be used for other purposes.  Huge pages can not be swapped out under
> +memory pressure.
> +
> +Once a number of huge pages have been pre-allocated to the kernel huge page
> +pool, a user with appropriate privilege can use either the mmap system call
> +or shared memory system calls to use the huge pages.  See the discussion of
> +Using Huge Pages, below
> +
> +The administrator can preallocate persistent huge pages on the kernel boot
> +command line by specifying the "hugepages=N" parameter, where 'N' = the
> +number of requested huge pages requested.  This is the most reliable method
> +or preallocating huge pages as memory has not yet become fragmented.
>  
>  Some platforms support multiple huge page sizes.  To preallocate huge pages
>  of a specific size, one must preceed the huge pages boot command parameters
> @@ -80,19 +77,24 @@ with a huge page size selection paramete
>  be specified in bytes with optional scale suffix [kKmMgG].  The default huge
>  page size may be selected with the "default_hugepagesz=<size>" boot parameter.
>  
> -/proc/sys/vm/nr_hugepages indicates the current number of configured [default
> -size] hugetlb pages in the kernel.  Super user can dynamically request more
> -(or free some pre-configured) huge pages.
> -
> -Use the following command to dynamically allocate/deallocate default sized
> -huge pages:
> +When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages
> +indicates the current number of pre-allocated huge pages of the default size.
> +Thus, one can use the following command to dynamically allocate/deallocate
> +default sized persistent huge pages:
>  
>  	echo 20 > /proc/sys/vm/nr_hugepages
>  
> -This command will try to configure 20 default sized huge pages in the system.
> +This command will try to adjust the number of default sized huge pages in the
> +huge page pool to 20, allocating or freeing huge pages, as required.
> +
>  On a NUMA platform, the kernel will attempt to distribute the huge page pool
> -over the all on-line nodes.  These huge pages, allocated when nr_hugepages
> -is increased, are called "persistent huge pages".
> +over the all the nodes specified by the NUMA memory policy of the task that

Remove the first 'the'.

> +modifies nr_hugepages that contain sufficient available contiguous memory.
> +These nodes are called the huge pages "allowed nodes".  The default for the

Not sure if you need to spell out that they're called "huge page allowed 
nodes," isn't that an implementation detail?  The way Paul Jackson used to 
describe nodes_allowed is "set of allowable nodes," and I can't think of a 
better phrase.  That's also how the cpuset documentation describes them.

> +huge pages allowed nodes--when the task has default memory policy--is all
> +on-line nodes.  See the discussion below of the interaction of task memory

All online nodes with memory, right?

> +policy, cpusets and per node attributes with the allocation and freeing of
> +persistent huge pages.
>  
>  The success or failure of huge page allocation depends on the amount of
>  physically contiguous memory that is preset in system at the time of the
> @@ -101,11 +103,11 @@ some nodes in a NUMA system, it will att
>  allocating extra pages on other nodes with sufficient available contiguous
>  memory, if any.
>  
> -System administrators may want to put this command in one of the local rc init
> -files.  This will enable the kernel to request huge pages early in the boot
> -process when the possibility of getting physical contiguous pages is still
> -very high.  Administrators can verify the number of huge pages actually
> -allocated by checking the sysctl or meminfo.  To check the per node
> +System administrators may want to put this command in one of the local rc
> +init files.  This will enable the kernel to preallocate huge pages early in
> +the boot process when the possibility of getting physical contiguous pages
> +is still very high.  Administrators can verify the number of huge pages
> +actually allocated by checking the sysctl or meminfo.  To check the per node
>  distribution of huge pages in a NUMA system, use:
>  
>  	cat /sys/devices/system/node/node*/meminfo | fgrep Huge
> @@ -113,39 +115,40 @@ distribution of huge pages in a NUMA sys
>  /proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of
>  huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are
>  requested by applications.  Writing any non-zero value into this file
> -indicates that the hugetlb subsystem is allowed to try to obtain "surplus"
> -huge pages from the buddy allocator, when the normal pool is exhausted. As
> -these surplus huge pages go out of use, they are freed back to the buddy
> -allocator.
> +indicates that the hugetlb subsystem is allowed to try to obtain that
> +number of "surplus" huge pages from the kernel's normal page pool, when the
> +persistent huge page pool is exhausted. As these surplus huge pages become
> +unused, they are freed back to the kernel's normal page pool.
>  
> -When increasing the huge page pool size via nr_hugepages, any surplus
> +When increasing the huge page pool size via nr_hugepages, any existing surplus
>  pages will first be promoted to persistent huge pages.  Then, additional
>  huge pages will be allocated, if necessary and if possible, to fulfill
> -the new huge page pool size.
> +the new persistent huge page pool size.
>  
>  The administrator may shrink the pool of preallocated huge pages for
>  the default huge page size by setting the nr_hugepages sysctl to a
>  smaller value.  The kernel will attempt to balance the freeing of huge pages
> -across all on-line nodes.  Any free huge pages on the selected nodes will
> -be freed back to the buddy allocator.
> -
> -Caveat: Shrinking the pool via nr_hugepages such that it becomes less
> -than the number of huge pages in use will convert the balance to surplus
> -huge pages even if it would exceed the overcommit value.  As long as
> -this condition holds, however, no more surplus huge pages will be
> -allowed on the system until one of the two sysctls are increased
> -sufficiently, or the surplus huge pages go out of use and are freed.
> +across all nodes in the memory policy of the task modifying nr_hugepages.
> +Any free huge pages on the selected nodes will be freed back to the kernel's
> +normal page pool.
> +
> +Caveat: Shrinking the persistent huge page pool via nr_hugepages such that
> +it becomes less than the number of huge pages in use will convert the balance
> +of the in-use huge pages to surplus huge pages.  This will occur even if
> +the number of surplus pages it would exceed the overcommit value.  As long as
> +this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is
> +increased sufficiently, or the surplus huge pages go out of use and are freed--
> +no more surplus huge pages will be allowed to be allocated.
>  

Nice description!

>  With support for multiple huge page pools at run-time available, much of
> -the huge page userspace interface has been duplicated in sysfs. The above
> -information applies to the default huge page size which will be
> -controlled by the /proc interfaces for backwards compatibility. The root
> -huge page control directory in sysfs is:
> +the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs.
> +The /proc interfaces discussed above have been retained for backwards
> +compatibility. The root huge page control directory in sysfs is:
>  
>  	/sys/kernel/mm/hugepages
>  
>  For each huge page size supported by the running kernel, a subdirectory
> -will exist, of the form
> +will exist, of the form:
>  
>  	hugepages-${size}kB
>  
> @@ -159,6 +162,98 @@ Inside each of these directories, the sa
>  
>  which function as described above for the default huge page-sized case.
>  
> +
> +Interaction of Task Memory Policy with Huge Page Allocation/Freeing:
> +
> +Whether huge pages are allocated and freed via the /proc interface or
> +the /sysfs interface, the NUMA nodes from which huge pages are allocated
> +or freed are controlled by the NUMA memory policy of the task that modifies
> +the nr_hugepages parameter.  [nr_overcommit_hugepages is a global limit.]
> +
> +The recommended method to allocate or free huge pages to/from the kernel
> +huge page pool, using the nr_hugepages example above, is:
> +
> +    numactl --interleave <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
> +
> +or, more succinctly:
> +
> +    numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
> +
> +This will allocate or free abs(20 - nr_hugepages) to or from the nodes
> +specified in <node-list>, depending on whether nr_hugepages is initially
> +less than or greater than 20, respectively.  No huge pages will be
> +allocated nor freed on any node not included in the specified <node-list>.
> +

This is actually why I was against the mempolicy approach to begin with: 
applications currently can free all hugepages on the system simply by 
writing to nr_hugepages, regardless of their mempolicy.  It's now possible 
that hugepages will remain allocated because they are on nodes disjoint 
from current->mempolicy->v.nodes.  I hope the advantages of this approach 
outweigh the potential userspace breakage of existing applications.

> +Any memory policy mode--bind, preferred, local or interleave--may be
> +used.  The effect on persistent huge page allocation will be as follows:
> +
> +1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt],
> +   persistent huge pages will be distributed across the node or nodes
> +   specified in the mempolicy as if "interleave" had been specified.
> +   However, if a node in the policy does not contain sufficient contiguous
> +   memory for a huge page, the allocation will not "fallback" to the nearest
> +   neighbor node with sufficient contiguous memory.  To do this would cause
> +   undesirable imbalance in the distribution of the huge page pool, or
> +   possibly, allocation of persistent huge pages on nodes not allowed by
> +   the task's memory policy.
> +

This is a good example of why the per-node tunables are helpful in case 
such a fallback is desired.

> +2) One or more nodes may be specified with the bind or interleave policy.
> +   If more than one node is specified with the preferred policy, only the
> +   lowest numeric id will be used.  Local policy will select the node where
> +   the task is running at the time the nodes_allowed mask is constructed.
> +
> +3) For local policy to be deterministic, the task must be bound to a cpu or
> +   cpus in a single node.  Otherwise, the task could be migrated to some
> +   other node at any time after launch and the resulting node will be
> +   indeterminate.  Thus, local policy is not very useful for this purpose.
> +   Any of the other mempolicy modes may be used to specify a single node.
> +
> +4) The nodes allowed mask will be derived from any non-default task mempolicy,
> +   whether this policy was set explicitly by the task itself or one of its
> +   ancestors, such as numactl.  This means that if the task is invoked from a
> +   shell with non-default policy, that policy will be used.  One can specify a
> +   node list of "all" with numactl --interleave or --membind [-m] to achieve
> +   interleaving over all nodes in the system or cpuset.
> +

Nice description.

> +5) Any task mempolicy specifed--e.g., using numactl--will be constrained by
> +   the resource limits of any cpuset in which the task runs.  Thus, there will
> +   be no way for a task with non-default policy running in a cpuset with a
> +   subset of the system nodes to allocate huge pages outside the cpuset
> +   without first moving to a cpuset that contains all of the desired nodes.
> +
> +6) Hugepages allocated at boot time always use the node_online_map.

Implementation detail in the name, maybe just say "all online nodes with 
memory"?

> +
> +
> +Per Node Hugepages Attributes
> +
> +A subset of the contents of the root huge page control directory in sysfs,
> +described above, has been replicated under each "node" system device in:
> +
> +	/sys/devices/system/node/node[0-9]*/hugepages/
> +
> +Under this directory, the subdirectory for each supported huge page size
> +contains the following attribute files:
> +
> +	nr_hugepages
> +	free_hugepages
> +	surplus_hugepages
> +
> +The free_' and surplus_' attribute files are read-only.  They return the number
> +of free and surplus [overcommitted] huge pages, respectively, on the parent
> +node.
> +
> +The nr_hugepages attribute will return the total number of huge pages on the
> +specified node.  When this attribute is written, the number of persistent huge
> +pages on the parent node will be adjusted to the specified value, if sufficient
> +resources exist, regardless of the task's mempolicy or cpuset constraints.
> +
> +Note that the number of overcommit and reserve pages remain global quantities,
> +as we don't know until fault time, when the faulting task's mempolicy is applied,
> +from which node the huge page allocation will be attempted.
> +
> +
> +Using Huge Pages:
> +
>  If the user applications are going to request huge pages using mmap system
>  call, then it is required that system administrator mount a file system of
>  type hugetlbfs:
> @@ -206,9 +301,11 @@ map_hugetlb.c.
>   * requesting huge pages.
>   *
>   * For the ia64 architecture, the Linux kernel reserves Region number 4 for
> - * huge pages.  That means the addresses starting with 0x800000... will need
> - * to be specified.  Specifying a fixed address is not required on ppc64,
> - * i386 or x86_64.
> + * huge pages.  That means that if one requires a fixed address, a huge page
> + * aligned address starting with 0x800000... will be required.  If a fixed
> + * address is not required, the kernel will select an address in the proper
> + * range.
> + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
>   *
>   * Note: The default shared memory limit is quite low on many kernels,
>   * you may need to increase it via:
> @@ -237,14 +334,8 @@ map_hugetlb.c.
>  
>  #define dprintf(x)  printf(x)
>  
> -/* Only ia64 requires this */
> -#ifdef __ia64__
> -#define ADDR (void *)(0x8000000000000000UL)
> -#define SHMAT_FLAGS (SHM_RND)
> -#else
> -#define ADDR (void *)(0x0UL)
> +#define ADDR (void *)(0x0UL)	/* let kernel choose address */
>  #define SHMAT_FLAGS (0)
> -#endif
>  
>  int main(void)
>  {
> @@ -302,10 +393,12 @@ int main(void)
>   * example, the app is requesting memory of size 256MB that is backed by
>   * huge pages.
>   *
> - * For ia64 architecture, Linux kernel reserves Region number 4 for huge pages.
> - * That means the addresses starting with 0x800000... will need to be
> - * specified.  Specifying a fixed address is not required on ppc64, i386
> - * or x86_64.
> + * For the ia64 architecture, the Linux kernel reserves Region number 4 for
> + * huge pages.  That means that if one requires a fixed address, a huge page
> + * aligned address starting with 0x800000... will be required.  If a fixed
> + * address is not required, the kernel will select an address in the proper
> + * range.
> + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
>   */
>  #include <stdlib.h>
>  #include <stdio.h>
> @@ -317,14 +410,8 @@ int main(void)
>  #define LENGTH (256UL*1024*1024)
>  #define PROTECTION (PROT_READ | PROT_WRITE)
>  
> -/* Only ia64 requires this */
> -#ifdef __ia64__
> -#define ADDR (void *)(0x8000000000000000UL)
> -#define FLAGS (MAP_SHARED | MAP_FIXED)
> -#else
> -#define ADDR (void *)(0x0UL)
> +#define ADDR (void *)(0x0UL)	/* let kernel choose address */
>  #define FLAGS (MAP_SHARED)
> -#endif
>  
>  void check_bytes(char *addr)
>  {
> 

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19])
	by kanga.kvack.org (Postfix) with ESMTP id E6D5A6B004F
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 16:15:37 -0400 (EDT)
Subject: Re: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from
 task mempolicy
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
In-Reply-To: <alpine.DEB.1.00.0909031212110.22173@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
	 <alpine.DEB.1.00.0909031212110.22173@chino.kir.corp.google.com>
Content-Type: text/plain
Date: Thu, 03 Sep 2009 16:15:40 -0400
Message-Id: <1252008940.6029.131.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Thu, 2009-09-03 at 12:22 -0700, David Rientjes wrote:
> 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.

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

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51])
	by kanga.kvack.org (Postfix) with ESMTP id E1CD26B004F
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 16:42:44 -0400 (EDT)
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
In-Reply-To: <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
	 <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
Content-Type: text/plain
Date: Thu, 03 Sep 2009 16:41:25 -0400
Message-Id: <1252010485.6029.180.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Thu, 2009-09-03 at 12:52 -0700, David Rientjes wrote:
> On Fri, 28 Aug 2009, Lee Schermerhorn wrote:
> 
> > Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
> > ===================================================================
> > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
> > +++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:31.000000000 -0400
> > @@ -24,6 +24,7 @@
> >  #include <asm/io.h>
> >  
> >  #include <linux/hugetlb.h>
> > +#include <linux/node.h>
> >  #include "internal.h"
> >  
> >  const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
> > @@ -1245,7 +1246,8 @@ static int adjust_pool_surplus(struct hs
> >  }
> >  
> >  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> > -static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
> > +static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> > +								int nid)
> >  {
> >  	unsigned long min_count, ret;
> >  	nodemask_t *nodes_allowed;
> > @@ -1253,7 +1255,21 @@ static unsigned long set_max_huge_pages(
> >  	if (h->order >= MAX_ORDER)
> >  		return h->max_huge_pages;
> >  
> > -	nodes_allowed = huge_mpol_nodes_allowed();
> > +	if (nid == NO_NODEID_SPECIFIED)
> > +		nodes_allowed = huge_mpol_nodes_allowed();
> > +	else {
> > +		/*
> > +		 * incoming 'count' is for node 'nid' only, so
> > +		 * adjust count to global, but restrict alloc/free
> > +		 * to the specified node.
> > +		 */
> > +		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
> > +		nodes_allowed = alloc_nodemask_of_node(nid);
> > +		if (!nodes_allowed)
> > +			printk(KERN_WARNING "%s unable to allocate allowed "
> > +			       "nodes mask for huge page allocation/free.  "
> > +			       "Falling back to default.\n", current->comm);
> > +	}
> >  
> >  	/*
> >  	 * Increase the pool size
> > @@ -1329,51 +1345,71 @@ out:
> >  static struct kobject *hugepages_kobj;
> >  static struct kobject *hstate_kobjs[HUGE_MAX_HSTATE];
> >  
> > -static struct hstate *kobj_to_hstate(struct kobject *kobj)
> > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp);
> > +
> > +static struct hstate *kobj_to_hstate(struct kobject *kobj, int *nidp)
> >  {
> >  	int i;
> > +
> >  	for (i = 0; i < HUGE_MAX_HSTATE; i++)
> > -		if (hstate_kobjs[i] == kobj)
> > +		if (hstate_kobjs[i] == kobj) {
> > +			if (nidp)
> > +				*nidp = NO_NODEID_SPECIFIED;
> >  			return &hstates[i];
> > -	BUG();
> > -	return NULL;
> > +		}
> > +
> > +	return kobj_to_node_hstate(kobj, nidp);
> >  }
> >  
> >  static ssize_t nr_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > -	return sprintf(buf, "%lu\n", h->nr_huge_pages);
> > +	struct hstate *h;
> > +	unsigned long nr_huge_pages;
> > +	int nid;
> > +
> > +	h = kobj_to_hstate(kobj, &nid);
> > +	if (nid == NO_NODEID_SPECIFIED)
> > +		nr_huge_pages = h->nr_huge_pages;
> > +	else
> > +		nr_huge_pages = h->nr_huge_pages_node[nid];
> > +
> > +	return sprintf(buf, "%lu\n", nr_huge_pages);
> >  }
> > +
> >  static ssize_t nr_hugepages_store(struct kobject *kobj,
> > -		struct kobj_attribute *attr, const char *buf, size_t count)
> > +		struct kobj_attribute *attr, const char *buf, size_t len)
> >  {
> > +	unsigned long count;
> > +	struct hstate *h;
> > +	int nid;
> >  	int err;
> > -	unsigned long input;
> > -	struct hstate *h = kobj_to_hstate(kobj);
> >  
> > -	err = strict_strtoul(buf, 10, &input);
> > +	err = strict_strtoul(buf, 10, &count);
> >  	if (err)
> >  		return 0;
> >  
> > -	h->max_huge_pages = set_max_huge_pages(h, input);
> > +	h = kobj_to_hstate(kobj, &nid);
> > +	h->max_huge_pages = set_max_huge_pages(h, count, nid);
> >  
> > -	return count;
> > +	return len;
> >  }
> >  HSTATE_ATTR(nr_hugepages);
> >  
> >  static ssize_t nr_overcommit_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> > +
> >  	return sprintf(buf, "%lu\n", h->nr_overcommit_huge_pages);
> >  }
> > +
> >  static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
> >  		struct kobj_attribute *attr, const char *buf, size_t count)
> >  {
> >  	int err;
> >  	unsigned long input;
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> >  
> >  	err = strict_strtoul(buf, 10, &input);
> >  	if (err)
> > @@ -1390,15 +1426,24 @@ HSTATE_ATTR(nr_overcommit_hugepages);
> >  static ssize_t free_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > -	return sprintf(buf, "%lu\n", h->free_huge_pages);
> > +	struct hstate *h;
> > +	unsigned long free_huge_pages;
> > +	int nid;
> > +
> > +	h = kobj_to_hstate(kobj, &nid);
> > +	if (nid == NO_NODEID_SPECIFIED)
> > +		free_huge_pages = h->free_huge_pages;
> > +	else
> > +		free_huge_pages = h->free_huge_pages_node[nid];
> > +
> > +	return sprintf(buf, "%lu\n", free_huge_pages);
> >  }
> >  HSTATE_ATTR_RO(free_hugepages);
> >  
> >  static ssize_t resv_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> >  	return sprintf(buf, "%lu\n", h->resv_huge_pages);
> >  }
> >  HSTATE_ATTR_RO(resv_hugepages);
> > @@ -1406,8 +1451,17 @@ HSTATE_ATTR_RO(resv_hugepages);
> >  static ssize_t surplus_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > -	return sprintf(buf, "%lu\n", h->surplus_huge_pages);
> > +	struct hstate *h;
> > +	unsigned long surplus_huge_pages;
> > +	int nid;
> > +
> > +	h = kobj_to_hstate(kobj, &nid);
> > +	if (nid == NO_NODEID_SPECIFIED)
> > +		surplus_huge_pages = h->surplus_huge_pages;
> > +	else
> > +		surplus_huge_pages = h->surplus_huge_pages_node[nid];
> > +
> > +	return sprintf(buf, "%lu\n", surplus_huge_pages);
> >  }
> >  HSTATE_ATTR_RO(surplus_hugepages);
> >  
> > @@ -1424,19 +1478,21 @@ static struct attribute_group hstate_att
> >  	.attrs = hstate_attrs,
> >  };
> >  
> > -static int __init hugetlb_sysfs_add_hstate(struct hstate *h)
> > +static int __init hugetlb_sysfs_add_hstate(struct hstate *h,
> > +				struct kobject *parent,
> > +				struct kobject **hstate_kobjs,
> > +				struct attribute_group *hstate_attr_group)
> >  {
> >  	int retval;
> > +	int hi = h - hstates;
> >  
> > -	hstate_kobjs[h - hstates] = kobject_create_and_add(h->name,
> > -							hugepages_kobj);
> > -	if (!hstate_kobjs[h - hstates])
> > +	hstate_kobjs[hi] = kobject_create_and_add(h->name, parent);
> > +	if (!hstate_kobjs[hi])
> >  		return -ENOMEM;
> >  
> > -	retval = sysfs_create_group(hstate_kobjs[h - hstates],
> > -							&hstate_attr_group);
> > +	retval = sysfs_create_group(hstate_kobjs[hi], hstate_attr_group);
> >  	if (retval)
> > -		kobject_put(hstate_kobjs[h - hstates]);
> > +		kobject_put(hstate_kobjs[hi]);
> >  
> >  	return retval;
> >  }
> > @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
> >  		return;
> >  
> >  	for_each_hstate(h) {
> > -		err = hugetlb_sysfs_add_hstate(h);
> > +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> > +					 hstate_kobjs, &hstate_attr_group);
> >  		if (err)
> >  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
> >  								h->name);
> >  	}
> >  }
> >  
> > +#ifdef CONFIG_NUMA
> > +
> > +struct node_hstate {
> > +	struct kobject		*hugepages_kobj;
> > +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> > +};
> > +struct node_hstate node_hstates[MAX_NUMNODES];
> > +
> > +static struct attribute *per_node_hstate_attrs[] = {
> > +	&nr_hugepages_attr.attr,
> > +	&free_hugepages_attr.attr,
> > +	&surplus_hugepages_attr.attr,
> > +	NULL,
> > +};
> > +
> > +static struct attribute_group per_node_hstate_attr_group = {
> > +	.attrs = per_node_hstate_attrs,
> > +};
> > +
> > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> > +{
> > +	int nid;
> > +
> > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > +		struct node_hstate *nhs = &node_hstates[nid];
> > +		int i;
> > +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> > +			if (nhs->hstate_kobjs[i] == kobj) {
> > +				if (nidp)
> > +					*nidp = nid;
> > +				return &hstates[i];
> > +			}
> > +	}
> > +
> > +	BUG();
> > +	return NULL;
> > +}
> > +
> > +void hugetlb_unregister_node(struct node *node)
> > +{
> > +	struct hstate *h;
> > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > +
> > +	if (!nhs->hugepages_kobj)
> > +		return;
> > +
> > +	for_each_hstate(h)
> > +		if (nhs->hstate_kobjs[h - hstates]) {
> > +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> > +			nhs->hstate_kobjs[h - hstates] = NULL;
> > +		}
> > +
> > +	kobject_put(nhs->hugepages_kobj);
> > +	nhs->hugepages_kobj = NULL;
> > +}
> > +
> > +static void hugetlb_unregister_all_nodes(void)
> > +{
> > +	int nid;
> > +
> > +	for (nid = 0; nid < nr_node_ids; nid++)
> > +		hugetlb_unregister_node(&node_devices[nid]);
> > +
> > +	register_hugetlbfs_with_node(NULL, NULL);
> > +}
> > +
> > +void hugetlb_register_node(struct node *node)
> > +{
> > +	struct hstate *h;
> > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > +	int err;
> > +
> > +	if (nhs->hugepages_kobj)
> > +		return;		/* already allocated */
> > +
> > +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> > +							&node->sysdev.kobj);
> > +	if (!nhs->hugepages_kobj)
> > +		return;
> > +
> > +	for_each_hstate(h) {
> > +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> > +						nhs->hstate_kobjs,
> > +						&per_node_hstate_attr_group);
> > +		if (err) {
> > +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> > +					" for node %d\n",
> > +						h->name, node->sysdev.id);
> 
> Maybe add `err' to the printk so we know whether it was an -ENOMEM 
> condition or sysfs problem?

Just the raw negative number?

> 
> > +			hugetlb_unregister_node(node);
> > +			break;
> > +		}
> > +	}
> > +}
> > +
> > +static void hugetlb_register_all_nodes(void)
> > +{
> > +	int nid;
> > +
> > +	for (nid = 0; nid < nr_node_ids; nid++) {
> 
> Don't you want to do this for all nodes in N_HIGH_MEMORY?  I don't think 
> we should be adding attributes for memoryless nodes.


Well, I wondered about that.  The persistent huge page allocation code
is careful to skip over nodes where it can't allow a huge page there,
whether or not the node has [any] memory.  So, it's safe to leave it
this way.  And, I was worried about the interaction with memory hotplug,
as separate from node hotplug.  The current code handles node hot plug,
bug I wasn't sure about memory hot-plug within a node.  I.e., would the
node driver get called to register the attributes in this case?   Maybe
that case doesn't exist, so I don't have to worry about it.   I think
this is somewhat similar to the top cpuset mems_allowed being set to all
possible to cover any subsequently added nodes/memory.

It's easy to change to use node_state[N_HIGH_MEMORY], but then the
memory hotplug guys might jump in and say that, now it doesn't work for
memory hot add/remove.  I really don't want to go there...

But, I can understand the confusion about providing an explicit control
like this for a node without memory.  It is somewhat different from just
visiting all online nodes for the default mask, as hugetlb.c has always
done.
  
> 
> > +		struct node *node = &node_devices[nid];
> > +		if (node->sysdev.id == nid)
> > +			hugetlb_register_node(node);
> > +	}
> > +
> > +	register_hugetlbfs_with_node(hugetlb_register_node,
> > +                                     hugetlb_unregister_node);
> > +}
> > +#else	/* !CONFIG_NUMA */
> > +
> > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> > +{
> > +	BUG();
> > +	if (nidp)
> > +		*nidp = -1;
> > +	return NULL;
> > +}
> > +
> > +static void hugetlb_unregister_all_nodes(void) { }
> > +
> > +static void hugetlb_register_all_nodes(void) { }
> > +
> > +#endif
> > +
> >  static void __exit hugetlb_exit(void)
> >  {
> >  	struct hstate *h;
> >  
> > +	hugetlb_unregister_all_nodes();
> > +
> >  	for_each_hstate(h) {
> >  		kobject_put(hstate_kobjs[h - hstates]);
> >  	}
> > @@ -1496,6 +1678,8 @@ static int __init hugetlb_init(void)
> >  
> >  	hugetlb_sysfs_init();
> >  
> > +	hugetlb_register_all_nodes();
> > +
> >  	return 0;
> >  }
> >  module_init(hugetlb_init);
> > @@ -1598,7 +1782,8 @@ int hugetlb_sysctl_handler(struct ctl_ta
> >  	proc_doulongvec_minmax(table, write, buffer, length, ppos);
> >  
> >  	if (write)
> > -		h->max_huge_pages = set_max_huge_pages(h, tmp);
> > +		h->max_huge_pages = set_max_huge_pages(h, tmp,
> > +		                                       NO_NODEID_SPECIFIED);
> >  
> >  	return 0;
> >  }
> > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
> > ===================================================================
> > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
> > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
> > @@ -10,4 +10,6 @@
> >  
> >  #define MAX_NUMNODES    (1 << NODES_SHIFT)
> >  
> > +#define NO_NODEID_SPECIFIED	(-1)
> > +
> >  #endif /* _LINUX_NUMA_H */
> 
> Hmm, so we already have NUMA_NO_NODE in the ia64 and x86_64 code and 
> NID_INVAL in the ACPI code, both of which are defined to -1.  Maybe rename 
> your addition here in favor of NUMA_NO_NODE, remove it from the ia64 and 
> x86 arch headers, and convert the ACPI code?

OK, replacing 'NO_NODEID_SPECIFIED' with 'NUMA_NO_NODE,' works w/o
decending into header dependency hell.  The symbol is already visible in
hugetlb.c  I'll fix that.  But, ACPI?  Not today, thanks :).  

> 
> Thanks for doing this!

Well, we do need this, as well.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Randy Dunlap <randy.dunlap@oracle.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
 mempolicy based management.
Date: Thu, 3 Sep 2009 13:42:10 -0700
Message-ID: <20090903134210.5a27611d.randy.dunlap@oracle.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	<20090828160351.11080.21379.sendpatchset@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <owner-linux-mm@kvack.org>
In-Reply-To: <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Fri, 28 Aug 2009 12:03:51 -0400 Lee Schermerhorn wrote:

(Thanks for cc:, David.)


> [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy based management.
> 
> Against: 2.6.31-rc7-mmotm-090827-0057
> 
> V2:  Add brief description of per node attributes.
> 
> This patch updates the kernel huge tlb documentation to describe the
> numa memory policy based huge page management.  Additionaly, the patch
> includes a fair amount of rework to improve consistency, eliminate
> duplication and set the context for documenting the memory policy
> interaction.
> 
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 
>  Documentation/vm/hugetlbpage.txt |  257 ++++++++++++++++++++++++++-------------
>  1 file changed, 172 insertions(+), 85 deletions(-)
> 
> Index: linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:16.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:32.000000000 -0400

> @@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
>  /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
>  in the kernel.
>  
> -/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
> -pages in the kernel.  Super user can dynamically request more (or free some
> -pre-configured) huge pages.
> -The allocation (or deallocation) of hugetlb pages is possible only if there are
> -enough physically contiguous free pages in system (freeing of huge pages is
> -possible only if there are enough hugetlb pages free that can be transferred
> -back to regular memory pool).
> -
> -Pages that are used as hugetlb pages are reserved inside the kernel and cannot
> -be used for other purposes.
> -
> -Once the kernel with Hugetlb page support is built and running, a user can
> -use either the mmap system call or shared memory system calls to start using
> -the huge pages.  It is required that the system administrator preallocate
> -enough memory for huge page purposes.
> -
> -The administrator can preallocate huge pages on the kernel boot command line by
> -specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
> -requested.  This is the most reliable method for preallocating huge pages as
> -memory has not yet become fragmented.
> +/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
> +allocated in the kernel's huge page pool.  These are called "persistent"
> +huge pages.  A user with root privileges can dynamically allocate more or
> +free some persistent huge pages by increasing or decreasing the value of
> +'nr_hugepages'.
> +
> +Pages that are used as huge pages are reserved inside the kernel and cannot
> +be used for other purposes.  Huge pages can not be swapped out under

                                           cannot

> +memory pressure.
> +
> +Once a number of huge pages have been pre-allocated to the kernel huge page
> +pool, a user with appropriate privilege can use either the mmap system call
> +or shared memory system calls to use the huge pages.  See the discussion of
> +Using Huge Pages, below

                     below.

> +
> +The administrator can preallocate persistent huge pages on the kernel boot
> +command line by specifying the "hugepages=N" parameter, where 'N' = the
> +number of requested huge pages requested.  This is the most reliable method

drop first "requested"

> +or preallocating huge pages as memory has not yet become fragmented.

   of

>  
>  Some platforms support multiple huge page sizes.  To preallocate huge pages
>  of a specific size, one must preceed the huge pages boot command parameters
> @@ -80,19 +77,24 @@ with a huge page size selection paramete
>  be specified in bytes with optional scale suffix [kKmMgG].  The default huge
>  page size may be selected with the "default_hugepagesz=<size>" boot parameter.
>  
> -/proc/sys/vm/nr_hugepages indicates the current number of configured [default
> -size] hugetlb pages in the kernel.  Super user can dynamically request more
> -(or free some pre-configured) huge pages.
> -
> -Use the following command to dynamically allocate/deallocate default sized
> -huge pages:
> +When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages
> +indicates the current number of pre-allocated huge pages of the default size.
> +Thus, one can use the following command to dynamically allocate/deallocate
> +default sized persistent huge pages:
>  
>  	echo 20 > /proc/sys/vm/nr_hugepages
>  
> -This command will try to configure 20 default sized huge pages in the system.
> +This command will try to adjust the number of default sized huge pages in the
> +huge page pool to 20, allocating or freeing huge pages, as required.
> +
>  On a NUMA platform, the kernel will attempt to distribute the huge page pool
> -over the all on-line nodes.  These huge pages, allocated when nr_hugepages
> -is increased, are called "persistent huge pages".
> +over the all the nodes specified by the NUMA memory policy of the task that

drop first "the"

> +modifies nr_hugepages that contain sufficient available contiguous memory.

whoa.  too many "that"s.  confusing.


> +These nodes are called the huge pages "allowed nodes".  The default for the
> +huge pages allowed nodes--when the task has default memory policy--is all
> +on-line nodes.  See the discussion below of the interaction of task memory
> +policy, cpusets and per node attributes with the allocation and freeing of
> +persistent huge pages.
>  
>  The success or failure of huge page allocation depends on the amount of
>  physically contiguous memory that is preset in system at the time of the
> @@ -101,11 +103,11 @@ some nodes in a NUMA system, it will att
...

> @@ -113,39 +115,40 @@ distribution of huge pages in a NUMA sys
>  /proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of
>  huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are
>  requested by applications.  Writing any non-zero value into this file
> -indicates that the hugetlb subsystem is allowed to try to obtain "surplus"
> -huge pages from the buddy allocator, when the normal pool is exhausted. As
> -these surplus huge pages go out of use, they are freed back to the buddy
> -allocator.
> +indicates that the hugetlb subsystem is allowed to try to obtain that
> +number of "surplus" huge pages from the kernel's normal page pool, when the
> +persistent huge page pool is exhausted. As these surplus huge pages become
> +unused, they are freed back to the kernel's normal page pool.
>  
> -When increasing the huge page pool size via nr_hugepages, any surplus
> +When increasing the huge page pool size via nr_hugepages, any existing surplus
>  pages will first be promoted to persistent huge pages.  Then, additional
>  huge pages will be allocated, if necessary and if possible, to fulfill
> -the new huge page pool size.
> +the new persistent huge page pool size.
>  
>  The administrator may shrink the pool of preallocated huge pages for
>  the default huge page size by setting the nr_hugepages sysctl to a
>  smaller value.  The kernel will attempt to balance the freeing of huge pages
> -across all on-line nodes.  Any free huge pages on the selected nodes will
> -be freed back to the buddy allocator.
> -
> -Caveat: Shrinking the pool via nr_hugepages such that it becomes less
> -than the number of huge pages in use will convert the balance to surplus
> -huge pages even if it would exceed the overcommit value.  As long as
> -this condition holds, however, no more surplus huge pages will be
> -allowed on the system until one of the two sysctls are increased
> -sufficiently, or the surplus huge pages go out of use and are freed.
> +across all nodes in the memory policy of the task modifying nr_hugepages.
> +Any free huge pages on the selected nodes will be freed back to the kernel's
> +normal page pool.
> +
> +Caveat: Shrinking the persistent huge page pool via nr_hugepages such that
> +it becomes less than the number of huge pages in use will convert the balance
> +of the in-use huge pages to surplus huge pages.  This will occur even if

                               surplus allocated huge pages
? vs. surplus available huge pages?

surplus (to me) implies available/unallocated...

Reading more below, I see that "surplus" here means "overcommitted".  oh well ;)


> +the number of surplus pages it would exceed the overcommit value.  As long as
> +this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is
> +increased sufficiently, or the surplus huge pages go out of use and are freed--
> +no more surplus huge pages will be allowed to be allocated.
>  
>  With support for multiple huge page pools at run-time available, much of
> -the huge page userspace interface has been duplicated in sysfs. The above
> -information applies to the default huge page size which will be
> -controlled by the /proc interfaces for backwards compatibility. The root
> -huge page control directory in sysfs is:
> +the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs.
> +The /proc interfaces discussed above have been retained for backwards
> +compatibility. The root huge page control directory in sysfs is:
>  
>  	/sys/kernel/mm/hugepages
>  
>  For each huge page size supported by the running kernel, a subdirectory
> -will exist, of the form
> +will exist, of the form:
>  
>  	hugepages-${size}kB
>  
> @@ -159,6 +162,98 @@ Inside each of these directories, the sa
>  
>  which function as described above for the default huge page-sized case.
>  
> +
> +Interaction of Task Memory Policy with Huge Page Allocation/Freeing:
> +
> +Whether huge pages are allocated and freed via the /proc interface or
> +the /sysfs interface, the NUMA nodes from which huge pages are allocated
> +or freed are controlled by the NUMA memory policy of the task that modifies
> +the nr_hugepages parameter.  [nr_overcommit_hugepages is a global limit.]
> +
> +The recommended method to allocate or free huge pages to/from the kernel
> +huge page pool, using the nr_hugepages example above, is:
> +
> +    numactl --interleave <node-list> echo 20 >/proc/sys/vm/nr_hugepages.

drop '.'

> +
> +or, more succinctly:
> +
> +    numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages.

ditto


> +
> +This will allocate or free abs(20 - nr_hugepages) to or from the nodes
> +specified in <node-list>, depending on whether nr_hugepages is initially
> +less than or greater than 20, respectively.  No huge pages will be
> +allocated nor freed on any node not included in the specified <node-list>.
> +
> +Any memory policy mode--bind, preferred, local or interleave--may be
> +used.  The effect on persistent huge page allocation will be as follows:

I would just use present tense as much as possible, e.g.,
                                             allocation is as follows:

> +
> +1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt],
> +   persistent huge pages will be distributed across the node or nodes
> +   specified in the mempolicy as if "interleave" had been specified.
> +   However, if a node in the policy does not contain sufficient contiguous
> +   memory for a huge page, the allocation will not "fallback" to the nearest
> +   neighbor node with sufficient contiguous memory.  To do this would cause
> +   undesirable imbalance in the distribution of the huge page pool, or
> +   possibly, allocation of persistent huge pages on nodes not allowed by
> +   the task's memory policy.
> +
> +2) One or more nodes may be specified with the bind or interleave policy.
> +   If more than one node is specified with the preferred policy, only the
> +   lowest numeric id will be used.  Local policy will select the node where
> +   the task is running at the time the nodes_allowed mask is constructed.
> +
> +3) For local policy to be deterministic, the task must be bound to a cpu or
> +   cpus in a single node.  Otherwise, the task could be migrated to some

I prefer s/cpu/CPU/ in all of Documentation/ text, but the cat is already out
of the bag on that.

> +   other node at any time after launch and the resulting node will be
> +   indeterminate.  Thus, local policy is not very useful for this purpose.
> +   Any of the other mempolicy modes may be used to specify a single node.
> +
> +4) The nodes allowed mask will be derived from any non-default task mempolicy,
> +   whether this policy was set explicitly by the task itself or one of its
> +   ancestors, such as numactl.  This means that if the task is invoked from a
> +   shell with non-default policy, that policy will be used.  One can specify a
> +   node list of "all" with numactl --interleave or --membind [-m] to achieve
> +   interleaving over all nodes in the system or cpuset.
> +
> +5) Any task mempolicy specifed--e.g., using numactl--will be constrained by
> +   the resource limits of any cpuset in which the task runs.  Thus, there will
> +   be no way for a task with non-default policy running in a cpuset with a
> +   subset of the system nodes to allocate huge pages outside the cpuset
> +   without first moving to a cpuset that contains all of the desired nodes.
> +
> +6) Hugepages allocated at boot time always use the node_online_map.
> +
> +
> +Per Node Hugepages Attributes
> +
> +A subset of the contents of the root huge page control directory in sysfs,
> +described above, has been replicated under each "node" system device in:
> +
> +	/sys/devices/system/node/node[0-9]*/hugepages/
> +
> +Under this directory, the subdirectory for each supported huge page size
> +contains the following attribute files:
> +
> +	nr_hugepages
> +	free_hugepages
> +	surplus_hugepages
> +
> +The free_' and surplus_' attribute files are read-only.  They return the number
> +of free and surplus [overcommitted] huge pages, respectively, on the parent
> +node.
> +
> +The nr_hugepages attribute will return the total number of huge pages on the
> +specified node.  When this attribute is written, the number of persistent huge
> +pages on the parent node will be adjusted to the specified value, if sufficient
> +resources exist, regardless of the task's mempolicy or cpuset constraints.
> +
> +Note that the number of overcommit and reserve pages remain global quantities,
> +as we don't know until fault time, when the faulting task's mempolicy is applied,
> +from which node the huge page allocation will be attempted.
> +
> +
> +Using Huge Pages:
> +
>  If the user applications are going to request huge pages using mmap system
>  call, then it is required that system administrator mount a file system of
>  type hugetlbfs:
> @@ -206,9 +301,11 @@ map_hugetlb.c.
...

> @@ -237,14 +334,8 @@ map_hugetlb.c.
...

> @@ -302,10 +393,12 @@ int main(void)
...

> @@ -317,14 +410,8 @@ int main(void)
...


---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35])
	by kanga.kvack.org (Postfix) with ESMTP id 80D706B005C
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 16:49:14 -0400 (EDT)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88])
	by smtp-out.google.com with ESMTP id n83KnGEX015425
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 21:49:16 +0100
Received: from pzk42 (pzk42.prod.google.com [10.243.19.170])
	by wpaz24.hot.corp.google.com with ESMTP id n83KkX54003753
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 13:49:13 -0700
Received: by pzk42 with SMTP id 42so181402pzk.19
        for <linux-mm@kvack.org>; Thu, 03 Sep 2009 13:49:13 -0700 (PDT)
Date: Thu, 3 Sep 2009 13:49:11 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from task
 mempolicy
In-Reply-To: <1252008940.6029.131.camel@useless.americas.hpqcorp.net>
Message-ID: <alpine.DEB.1.00.0909031342520.30662@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160332.11080.74896.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031212110.22173@chino.kir.corp.google.com>
 <1252008940.6029.131.camel@useless.americas.hpqcorp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

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>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
Date: Thu, 03 Sep 2009 16:49:48 -0400
Message-ID: <1252010988.6029.194.camel@useless.americas.hpqcorp.net>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160338.11080.51282.sendpatchset@localhost.localdomain>
	 <20090901144932.GB7548@csn.ul.ie>
	 <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
	 <alpine.DEB.1.00.0909031122590.9055@chino.kir.corp.google.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <owner-linux-mm@kvack.org>
In-Reply-To: <alpine.DEB.1.00.0909031122590.9055@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: David Rientjes <rientjes@google.com>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Thu, 2009-09-03 at 11:34 -0700, David Rientjes wrote:
> On Tue, 1 Sep 2009, Lee Schermerhorn wrote:
> 
> > > > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
> > > > ===================================================================
> > > > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h	2009-08-28 09:21:19.000000000 -0400
> > > > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h	2009-08-28 09:21:29.000000000 -0400
> > > > @@ -245,18 +245,34 @@ static inline int __next_node(int n, con
> > > >  	return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
> > > >  }
> > > >  
> > > > +#define init_nodemask_of_nodes(mask, node)				\
> > > > +	nodes_clear(*(mask));						\
> > > > +	node_set((node), *(mask));
> > > > +
> > > 
> > > Is the done thing to either make this a static inline or else wrap it in
> > > a do { } while(0) ? The reasoning being that if this is used as part of an
> > > another statement (e.g. a for loop) that it'll actually compile instead of
> > > throw up weird error messages.
> > 
> > Right.  I'll fix this [and signoff/review orders] next time [maybe last
> > time?].  It occurs to me that I can also use this for
> > huge_mpol_nodes_allowed(), so I'll move it up in the series and fix that
> > [which you've already ack'd].  I'll wait a bit to hear from David before
> > I respin.
> > 
> 
> I think it should be an inline function just so there's typechecking on 
> the first argument passed in (and so alloc_nodemask_of_node() below 
> doesn't get a NULL pointer dereference on node_set() if nmp can't be 
> allocated).

OK.  That works.  will be in v6

> 
> I've seen the issue about the signed-off-by/reviewed-by/acked-by order 
> come up before.  I've always put my signed-off-by line last whenever 
> proposing patches because it shows a clear order in who gathered those 
> lines when submitting to -mm, for example.  If I write
> 
> 	Cc: Mel Gorman <mel@csn.ul.ie>
> 	Signed-off-by: David Rientjes <rientjes@google.com>
> 
> it is clear that I cc'd Mel on the initial proposal.  If it is the other 
> way around, for example,
> 
> 	Signed-off-by: David Rientjes <rientjes@google.com>
> 	Cc: Mel Gorman <mel@csn.ul.ie>
> 	Signed-off-by: Andrew Morton...
> 
> then it indicates Andrew added the cc when merging into -mm.  That's more 
> relevant when such a line is acked-by or reviewed-by since it is now 
> possible to determine who received such acknowledgement from the 
> individual and is responsible for correctly relaying it in the patch 
> submission.
> 
> If it's done this way, it indicates that whoever is signing off the patch 
> is responsible for everything above it.  The type of line (signed-off-by, 
> reviewed-by, acked-by) is enough of an indication about the development 
> history of the patch, I believe, and it doesn't require specific ordering 
> to communicate (and the first line having to be a signed-off-by line isn't 
> really important, it doesn't replace the From: line).
> 
> It also appears to be how both Linus merges his own patches with Cc's.

???

> 
> > > > +/*
> > > > + * returns pointer to kmalloc()'d nodemask initialized to contain the
> > > > + * specified node.  Caller must free with kfree().
> > > > + */
> > > > +#define alloc_nodemask_of_node(node)					\
> > > > +({									\
> > > > +	typeof(_unused_nodemask_arg_) *nmp;				\
> > > > +	nmp = kmalloc(sizeof(*nmp), GFP_KERNEL);			\
> > > > +	if (nmp)							\
> > > > +		init_nodemask_of_nodes(nmp, (node));			\
> > > > +	nmp;								\
> > > > +})
> > > > +
> > > 

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243])
	by kanga.kvack.org (Postfix) with ESMTP id B378E6B005C
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 17:02:10 -0400 (EDT)
Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75])
	by smtp-out.google.com with ESMTP id n83L24qC021780
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 22:02:05 +0100
Received: from pxi8 (pxi8.prod.google.com [10.243.27.8])
	by zps75.corp.google.com with ESMTP id n83L14KS005523
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 14:02:02 -0700
Received: by pxi8 with SMTP id 8so189036pxi.9
        for <linux-mm@kvack.org>; Thu, 03 Sep 2009 14:02:02 -0700 (PDT)
Date: Thu, 3 Sep 2009 14:02:00 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
In-Reply-To: <1252010485.6029.180.camel@useless.americas.hpqcorp.net>
Message-ID: <alpine.DEB.1.00.0909031350030.30662@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160344.11080.20255.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
 <1252010485.6029.180.camel@useless.americas.hpqcorp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Thu, 3 Sep 2009, Lee Schermerhorn wrote:

> > > @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
> > >  		return;
> > >  
> > >  	for_each_hstate(h) {
> > > -		err = hugetlb_sysfs_add_hstate(h);
> > > +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> > > +					 hstate_kobjs, &hstate_attr_group);
> > >  		if (err)
> > >  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
> > >  								h->name);
> > >  	}
> > >  }
> > >  
> > > +#ifdef CONFIG_NUMA
> > > +
> > > +struct node_hstate {
> > > +	struct kobject		*hugepages_kobj;
> > > +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> > > +};
> > > +struct node_hstate node_hstates[MAX_NUMNODES];
> > > +
> > > +static struct attribute *per_node_hstate_attrs[] = {
> > > +	&nr_hugepages_attr.attr,
> > > +	&free_hugepages_attr.attr,
> > > +	&surplus_hugepages_attr.attr,
> > > +	NULL,
> > > +};
> > > +
> > > +static struct attribute_group per_node_hstate_attr_group = {
> > > +	.attrs = per_node_hstate_attrs,
> > > +};
> > > +
> > > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> > > +{
> > > +	int nid;
> > > +
> > > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > > +		struct node_hstate *nhs = &node_hstates[nid];
> > > +		int i;
> > > +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> > > +			if (nhs->hstate_kobjs[i] == kobj) {
> > > +				if (nidp)
> > > +					*nidp = nid;
> > > +				return &hstates[i];
> > > +			}
> > > +	}
> > > +
> > > +	BUG();
> > > +	return NULL;
> > > +}
> > > +
> > > +void hugetlb_unregister_node(struct node *node)
> > > +{
> > > +	struct hstate *h;
> > > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > > +
> > > +	if (!nhs->hugepages_kobj)
> > > +		return;
> > > +
> > > +	for_each_hstate(h)
> > > +		if (nhs->hstate_kobjs[h - hstates]) {
> > > +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> > > +			nhs->hstate_kobjs[h - hstates] = NULL;
> > > +		}
> > > +
> > > +	kobject_put(nhs->hugepages_kobj);
> > > +	nhs->hugepages_kobj = NULL;
> > > +}
> > > +
> > > +static void hugetlb_unregister_all_nodes(void)
> > > +{
> > > +	int nid;
> > > +
> > > +	for (nid = 0; nid < nr_node_ids; nid++)
> > > +		hugetlb_unregister_node(&node_devices[nid]);
> > > +
> > > +	register_hugetlbfs_with_node(NULL, NULL);
> > > +}
> > > +
> > > +void hugetlb_register_node(struct node *node)
> > > +{
> > > +	struct hstate *h;
> > > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > > +	int err;
> > > +
> > > +	if (nhs->hugepages_kobj)
> > > +		return;		/* already allocated */
> > > +
> > > +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> > > +							&node->sysdev.kobj);
> > > +	if (!nhs->hugepages_kobj)
> > > +		return;
> > > +
> > > +	for_each_hstate(h) {
> > > +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> > > +						nhs->hstate_kobjs,
> > > +						&per_node_hstate_attr_group);
> > > +		if (err) {
> > > +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> > > +					" for node %d\n",
> > > +						h->name, node->sysdev.id);
> > 
> > Maybe add `err' to the printk so we know whether it was an -ENOMEM 
> > condition or sysfs problem?
> 
> Just the raw negative number?
> 

Sure.  I'm making the assumption that the printk is actually necessary in 
the first place, which is rather unorthodox for functions that can 
otherwise silently recover by unregistering the attribute.  Using the 
printk implies you want to know about the failure, yet additional 
debugging would be necessary to even identify what the failure was without 
printing the errno.

> > 
> > > +			hugetlb_unregister_node(node);
> > > +			break;
> > > +		}
> > > +	}
> > > +}
> > > +
> > > +static void hugetlb_register_all_nodes(void)
> > > +{
> > > +	int nid;
> > > +
> > > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > 
> > Don't you want to do this for all nodes in N_HIGH_MEMORY?  I don't think 
> > we should be adding attributes for memoryless nodes.
> 
> 
> Well, I wondered about that.  The persistent huge page allocation code
> is careful to skip over nodes where it can't allow a huge page there,
> whether or not the node has [any] memory.  So, it's safe to leave it
> this way.

It's safe, but it seems inconsistent to allow hugepage attributes to 
appear in /sys/devices/node/node* for nodes that have no memory.

> And, I was worried about the interaction with memory hotplug,
> as separate from node hotplug.  The current code handles node hot plug,
> bug I wasn't sure about memory hot-plug within a node.

If memory hotplug doesn't update nodes_state[N_HIGH_MEMORY] then there are 
plenty of other users that will currently fail as well.

> I.e., would the
> node driver get called to register the attributes in this case?

Not without a MEM_ONLINE notifier.

> Maybe
> that case doesn't exist, so I don't have to worry about it.   I think
> this is somewhat similar to the top cpuset mems_allowed being set to all
> possible to cover any subsequently added nodes/memory.
> 

That's because the page allocator's zonelists won't try to allocate from a 
memoryless node and the only hook into the cpuset code in that path is to 
check whether a nid is set in cpuset_current_mems_allowed.  It's quite 
different from providing per-node allocation and freeing mechanisms for 
pages on nodes without memory like this approach.

> > > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
> > > ===================================================================
> > > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
> > > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
> > > @@ -10,4 +10,6 @@
> > >  
> > >  #define MAX_NUMNODES    (1 << NODES_SHIFT)
> > >  
> > > +#define NO_NODEID_SPECIFIED	(-1)
> > > +
> > >  #endif /* _LINUX_NUMA_H */
> > 
> > Hmm, so we already have NUMA_NO_NODE in the ia64 and x86_64 code and 
> > NID_INVAL in the ACPI code, both of which are defined to -1.  Maybe rename 
> > your addition here in favor of NUMA_NO_NODE, remove it from the ia64 and 
> > x86 arch headers, and convert the ACPI code?
> 
> OK, replacing 'NO_NODEID_SPECIFIED' with 'NUMA_NO_NODE,' works w/o
> decending into header dependency hell.  The symbol is already visible in
> hugetlb.c  I'll fix that.

NUMA_NO_NODE may be visible in hugetlb.c for ia64 and x86, but probably 
not for other architectures so it should be moved to include/linux/numa.h.

> But, ACPI?  Not today, thanks :).

Darn :)

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35])
	by kanga.kvack.org (Postfix) with ESMTP id 3A1A86B005C
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 17:04:01 -0400 (EDT)
Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78])
	by smtp-out.google.com with ESMTP id n83L3wrX003137
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 14:03:58 -0700
Received: from pxi7 (pxi7.prod.google.com [10.243.27.7])
	by zps78.corp.google.com with ESMTP id n83L3soI021041
	for <linux-mm@kvack.org>; Thu, 3 Sep 2009 14:03:56 -0700
Received: by pxi7 with SMTP id 7so186516pxi.1
        for <linux-mm@kvack.org>; Thu, 03 Sep 2009 14:03:56 -0700 (PDT)
Date: Thu, 3 Sep 2009 14:03:55 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
In-Reply-To: <1252010988.6029.194.camel@useless.americas.hpqcorp.net>
Message-ID: <alpine.DEB.1.00.0909031402340.30662@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160338.11080.51282.sendpatchset@localhost.localdomain> <20090901144932.GB7548@csn.ul.ie> <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
 <alpine.DEB.1.00.0909031122590.9055@chino.kir.corp.google.com> <1252010988.6029.194.camel@useless.americas.hpqcorp.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Thu, 3 Sep 2009, Lee Schermerhorn wrote:

> > I've seen the issue about the signed-off-by/reviewed-by/acked-by order 
> > come up before.  I've always put my signed-off-by line last whenever 
> > proposing patches because it shows a clear order in who gathered those 
> > lines when submitting to -mm, for example.  If I write
> > 
> > 	Cc: Mel Gorman <mel@csn.ul.ie>
> > 	Signed-off-by: David Rientjes <rientjes@google.com>
> > 
> > it is clear that I cc'd Mel on the initial proposal.  If it is the other 
> > way around, for example,
> > 
> > 	Signed-off-by: David Rientjes <rientjes@google.com>
> > 	Cc: Mel Gorman <mel@csn.ul.ie>
> > 	Signed-off-by: Andrew Morton...
> > 
> > then it indicates Andrew added the cc when merging into -mm.  That's more 
> > relevant when such a line is acked-by or reviewed-by since it is now 
> > possible to determine who received such acknowledgement from the 
> > individual and is responsible for correctly relaying it in the patch 
> > submission.
> > 
> > If it's done this way, it indicates that whoever is signing off the patch 
> > is responsible for everything above it.  The type of line (signed-off-by, 
> > reviewed-by, acked-by) is enough of an indication about the development 
> > history of the patch, I believe, and it doesn't require specific ordering 
> > to communicate (and the first line having to be a signed-off-by line isn't 
> > really important, it doesn't replace the From: line).
> > 
> > It also appears to be how both Linus merges his own patches with Cc's.
> 
> ???
> 

Not sure what's confusing about this, sorry.  You order your 
acked-by/reviewed-by/signed-off-by lines just like I have for years and I 
don't think it needs to be changed.  It shows a clear history of who did 
what in the path from original developer -> maintainer -> Linus.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243])
	by kanga.kvack.org (Postfix) with ESMTP id AE2626B005C
	for <linux-mm@kvack.org>; Thu,  3 Sep 2009 17:09:18 -0400 (EDT)
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
 mempolicy based management.
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
In-Reply-To: <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
	 <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com>
Content-Type: text/plain
Date: Thu, 03 Sep 2009 17:09:18 -0400
Message-Id: <1252012158.6029.215.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Thu, 2009-09-03 at 13:07 -0700, David Rientjes wrote:
> On Fri, 28 Aug 2009, Lee Schermerhorn wrote:
> 
> > [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy based management.
> > 
> > Against: 2.6.31-rc7-mmotm-090827-0057
> > 
> > V2:  Add brief description of per node attributes.
> > 
> > This patch updates the kernel huge tlb documentation to describe the
> > numa memory policy based huge page management.  Additionaly, the patch
> > includes a fair amount of rework to improve consistency, eliminate
> > duplication and set the context for documenting the memory policy
> > interaction.
> > 
> > Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 
> Adding Randy to the cc.  Comments below, but otherwise:
> 
> Acked-by: David Rientjes <rientjes@google.com>
> 
> > 
> >  Documentation/vm/hugetlbpage.txt |  257 ++++++++++++++++++++++++++-------------
> >  1 file changed, 172 insertions(+), 85 deletions(-)
> > 
> > Index: linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt
> > ===================================================================
> > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:16.000000000 -0400
> > +++ linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:32.000000000 -0400
> > @@ -11,23 +11,21 @@ This optimization is more critical now a
> >  (several GBs) are more readily available.
> >  
> >  Users can use the huge page support in Linux kernel by either using the mmap
> > -system call or standard SYSv shared memory system calls (shmget, shmat).
> > +system call or standard SYSV shared memory system calls (shmget, shmat).
> >  
> >  First the Linux kernel needs to be built with the CONFIG_HUGETLBFS
> >  (present under "File systems") and CONFIG_HUGETLB_PAGE (selected
> >  automatically when CONFIG_HUGETLBFS is selected) configuration
> >  options.
> >  
> > -The kernel built with huge page support should show the number of configured
> > -huge pages in the system by running the "cat /proc/meminfo" command.
> > +The /proc/meminfo file provides information about the total number of hugetlb
> > +pages preallocated in the kernel's huge page pool.  It also displays
> > +information about the number of free, reserved and surplus huge pages and the
> > +[default] huge page size.  The huge page size is needed for generating the
> 
> Don't think the brackets are needed.

will fix

> 
> > +proper alignment and size of the arguments to system calls that map huge page
> > +regions.
> >  
> > -/proc/meminfo also provides information about the total number of hugetlb
> > -pages configured in the kernel.  It also displays information about the
> > -number of free hugetlb pages at any time.  It also displays information about
> > -the configured huge page size - this is needed for generating the proper
> > -alignment and size of the arguments to the above system calls.
> > -
> > -The output of "cat /proc/meminfo" will have lines like:
> > +The output of "cat /proc/meminfo" will include lines like:
> >  
> >  .....
> >  HugePages_Total: vvv
> > @@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
> >  /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
> >  in the kernel.
> >  
> > -/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
> > -pages in the kernel.  Super user can dynamically request more (or free some
> > -pre-configured) huge pages.
> > -The allocation (or deallocation) of hugetlb pages is possible only if there are
> > -enough physically contiguous free pages in system (freeing of huge pages is
> > -possible only if there are enough hugetlb pages free that can be transferred
> > -back to regular memory pool).
> > -
> > -Pages that are used as hugetlb pages are reserved inside the kernel and cannot
> > -be used for other purposes.
> > -
> > -Once the kernel with Hugetlb page support is built and running, a user can
> > -use either the mmap system call or shared memory system calls to start using
> > -the huge pages.  It is required that the system administrator preallocate
> > -enough memory for huge page purposes.
> > -
> > -The administrator can preallocate huge pages on the kernel boot command line by
> > -specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
> > -requested.  This is the most reliable method for preallocating huge pages as
> > -memory has not yet become fragmented.
> > +/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
> > +allocated in the kernel's huge page pool.  These are called "persistent"
> > +huge pages.  A user with root privileges can dynamically allocate more or
> > +free some persistent huge pages by increasing or decreasing the value of
> > +'nr_hugepages'.
> > +
> 
> So they're not necessarily "preallocated" then if they're already in use.

I don't see what in the text you're referring to"  "preallocated" vs
"already in use" ???

> 
> > +Pages that are used as huge pages are reserved inside the kernel and cannot
> > +be used for other purposes.  Huge pages can not be swapped out under
> > +memory pressure.
> > +
> > +Once a number of huge pages have been pre-allocated to the kernel huge page
> > +pool, a user with appropriate privilege can use either the mmap system call
> > +or shared memory system calls to use the huge pages.  See the discussion of
> > +Using Huge Pages, below
> > +
> > +The administrator can preallocate persistent huge pages on the kernel boot
> > +command line by specifying the "hugepages=N" parameter, where 'N' = the
> > +number of requested huge pages requested.  This is the most reliable method
> > +or preallocating huge pages as memory has not yet become fragmented.
> >  
> >  Some platforms support multiple huge page sizes.  To preallocate huge pages
> >  of a specific size, one must preceed the huge pages boot command parameters
> > @@ -80,19 +77,24 @@ with a huge page size selection paramete
> >  be specified in bytes with optional scale suffix [kKmMgG].  The default huge
> >  page size may be selected with the "default_hugepagesz=<size>" boot parameter.
> >  
> > -/proc/sys/vm/nr_hugepages indicates the current number of configured [default
> > -size] hugetlb pages in the kernel.  Super user can dynamically request more
> > -(or free some pre-configured) huge pages.
> > -
> > -Use the following command to dynamically allocate/deallocate default sized
> > -huge pages:
> > +When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages
> > +indicates the current number of pre-allocated huge pages of the default size.
> > +Thus, one can use the following command to dynamically allocate/deallocate
> > +default sized persistent huge pages:
> >  
> >  	echo 20 > /proc/sys/vm/nr_hugepages
> >  
> > -This command will try to configure 20 default sized huge pages in the system.
> > +This command will try to adjust the number of default sized huge pages in the
> > +huge page pool to 20, allocating or freeing huge pages, as required.
> > +
> >  On a NUMA platform, the kernel will attempt to distribute the huge page pool
> > -over the all on-line nodes.  These huge pages, allocated when nr_hugepages
> > -is increased, are called "persistent huge pages".
> > +over the all the nodes specified by the NUMA memory policy of the task that
> 
> Remove the first 'the'.

OK.

> 
> > +modifies nr_hugepages that contain sufficient available contiguous memory.
> > +These nodes are called the huge pages "allowed nodes".  The default for the
> 
> Not sure if you need to spell out that they're called "huge page allowed 
> nodes," isn't that an implementation detail?  The way Paul Jackson used to 
> describe nodes_allowed is "set of allowable nodes," and I can't think of a 
> better phrase.  That's also how the cpuset documentation describes them.

I wanted to refer to "huge pages allowed nodes" to differentiate from,
e.g., cpusets mems_allowed"--i.e., I wanted the "huge pages" qualifier.
I suppose I could introduce the phrase you suggest:  "set of allowable
nodes" and emphasize that in this doc, it only refers to nodes from
which persistent huge pages will be allocated.

> 
> > +huge pages allowed nodes--when the task has default memory policy--is all
> > +on-line nodes.  See the discussion below of the interaction of task memory
> 
> All online nodes with memory, right?

See response to comment on patch 5/6.  We can only allocate huge pages
from nodes that have them available, but the current code [before these
patches] does visit all on-line nodes.  As I mentioned, changing this
could have hotplug {imp|comp}lications, and for this patch set, I don't
want to go there.

> 
> > +policy, cpusets and per node attributes with the allocation and freeing of
> > +persistent huge pages.
> >  
> >  The success or failure of huge page allocation depends on the amount of
> >  physically contiguous memory that is preset in system at the time of the
> > @@ -101,11 +103,11 @@ some nodes in a NUMA system, it will att
> >  allocating extra pages on other nodes with sufficient available contiguous
> >  memory, if any.
> >  
> > -System administrators may want to put this command in one of the local rc init
> > -files.  This will enable the kernel to request huge pages early in the boot
> > -process when the possibility of getting physical contiguous pages is still
> > -very high.  Administrators can verify the number of huge pages actually
> > -allocated by checking the sysctl or meminfo.  To check the per node
> > +System administrators may want to put this command in one of the local rc
> > +init files.  This will enable the kernel to preallocate huge pages early in
> > +the boot process when the possibility of getting physical contiguous pages
> > +is still very high.  Administrators can verify the number of huge pages
> > +actually allocated by checking the sysctl or meminfo.  To check the per node
> >  distribution of huge pages in a NUMA system, use:
> >  
> >  	cat /sys/devices/system/node/node*/meminfo | fgrep Huge
> > @@ -113,39 +115,40 @@ distribution of huge pages in a NUMA sys
> >  /proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of
> >  huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are
> >  requested by applications.  Writing any non-zero value into this file
> > -indicates that the hugetlb subsystem is allowed to try to obtain "surplus"
> > -huge pages from the buddy allocator, when the normal pool is exhausted. As
> > -these surplus huge pages go out of use, they are freed back to the buddy
> > -allocator.
> > +indicates that the hugetlb subsystem is allowed to try to obtain that
> > +number of "surplus" huge pages from the kernel's normal page pool, when the
> > +persistent huge page pool is exhausted. As these surplus huge pages become
> > +unused, they are freed back to the kernel's normal page pool.
> >  
> > -When increasing the huge page pool size via nr_hugepages, any surplus
> > +When increasing the huge page pool size via nr_hugepages, any existing surplus
> >  pages will first be promoted to persistent huge pages.  Then, additional
> >  huge pages will be allocated, if necessary and if possible, to fulfill
> > -the new huge page pool size.
> > +the new persistent huge page pool size.
> >  
> >  The administrator may shrink the pool of preallocated huge pages for
> >  the default huge page size by setting the nr_hugepages sysctl to a
> >  smaller value.  The kernel will attempt to balance the freeing of huge pages
> > -across all on-line nodes.  Any free huge pages on the selected nodes will
> > -be freed back to the buddy allocator.
> > -
> > -Caveat: Shrinking the pool via nr_hugepages such that it becomes less
> > -than the number of huge pages in use will convert the balance to surplus
> > -huge pages even if it would exceed the overcommit value.  As long as
> > -this condition holds, however, no more surplus huge pages will be
> > -allowed on the system until one of the two sysctls are increased
> > -sufficiently, or the surplus huge pages go out of use and are freed.
> > +across all nodes in the memory policy of the task modifying nr_hugepages.
> > +Any free huge pages on the selected nodes will be freed back to the kernel's
> > +normal page pool.
> > +
> > +Caveat: Shrinking the persistent huge page pool via nr_hugepages such that
> > +it becomes less than the number of huge pages in use will convert the balance
> > +of the in-use huge pages to surplus huge pages.  This will occur even if
> > +the number of surplus pages it would exceed the overcommit value.  As long as
> > +this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is
> > +increased sufficiently, or the surplus huge pages go out of use and are freed--
> > +no more surplus huge pages will be allowed to be allocated.
> >  
> 
> Nice description!
> 
> >  With support for multiple huge page pools at run-time available, much of
> > -the huge page userspace interface has been duplicated in sysfs. The above
> > -information applies to the default huge page size which will be
> > -controlled by the /proc interfaces for backwards compatibility. The root
> > -huge page control directory in sysfs is:
> > +the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs.
> > +The /proc interfaces discussed above have been retained for backwards
> > +compatibility. The root huge page control directory in sysfs is:
> >  
> >  	/sys/kernel/mm/hugepages
> >  
> >  For each huge page size supported by the running kernel, a subdirectory
> > -will exist, of the form
> > +will exist, of the form:
> >  
> >  	hugepages-${size}kB
> >  
> > @@ -159,6 +162,98 @@ Inside each of these directories, the sa
> >  
> >  which function as described above for the default huge page-sized case.
> >  
> > +
> > +Interaction of Task Memory Policy with Huge Page Allocation/Freeing:
> > +
> > +Whether huge pages are allocated and freed via the /proc interface or
> > +the /sysfs interface, the NUMA nodes from which huge pages are allocated
> > +or freed are controlled by the NUMA memory policy of the task that modifies
> > +the nr_hugepages parameter.  [nr_overcommit_hugepages is a global limit.]
> > +
> > +The recommended method to allocate or free huge pages to/from the kernel
> > +huge page pool, using the nr_hugepages example above, is:
> > +
> > +    numactl --interleave <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
> > +
> > +or, more succinctly:
> > +
> > +    numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
> > +
> > +This will allocate or free abs(20 - nr_hugepages) to or from the nodes
> > +specified in <node-list>, depending on whether nr_hugepages is initially
> > +less than or greater than 20, respectively.  No huge pages will be
> > +allocated nor freed on any node not included in the specified <node-list>.
> > +
> 
> This is actually why I was against the mempolicy approach to begin with: 
> applications currently can free all hugepages on the system simply by 
> writing to nr_hugepages, regardless of their mempolicy.  It's now possible 
> that hugepages will remain allocated because they are on nodes disjoint 
> from current->mempolicy->v.nodes.  I hope the advantages of this approach 
> outweigh the potential userspace breakage of existing applications.

I understand.  However, I do think it's useful to support both a mask
[and Mel prefers it be based on mempolicy] and per node attributes.  On
some of our platforms, we do want explicit control over the placement of
huge pages--e.g., for a data base shared area or such.  So, we can say,
"I need <N> huge pages, and I want them on nodes 1, 3, 4 and 5", and
then, assuming we start with no huge pages allocated [free them all if
this is not the case]:

	numactl -m 1,3-5 hugeadm --pool-pages-min 2M:<N>

Later, if I decide that maybe I want to adjust the number on node 1, I
can:

	numactl -m 1 --pool-pages-min 2M:{+|-}<count>

or:

	echo <new-value> >/sys/devices/system/node/node1/hugepages/hugepages-2048KB/nr_hugepages

[Of course, I'd probably do this in a script to avoid all that typing :)]

> > +Any memory policy mode--bind, preferred, local or interleave--may be
> > +used.  The effect on persistent huge page allocation will be as follows:
> > +
> > +1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt],
> > +   persistent huge pages will be distributed across the node or nodes
> > +   specified in the mempolicy as if "interleave" had been specified.
> > +   However, if a node in the policy does not contain sufficient contiguous
> > +   memory for a huge page, the allocation will not "fallback" to the nearest
> > +   neighbor node with sufficient contiguous memory.  To do this would cause
> > +   undesirable imbalance in the distribution of the huge page pool, or
> > +   possibly, allocation of persistent huge pages on nodes not allowed by
> > +   the task's memory policy.
> > +
> 
> This is a good example of why the per-node tunables are helpful in case 
> such a fallback is desired.

Agreed.  And the fact that they do bypass any mempolicy.

> 
> > +2) One or more nodes may be specified with the bind or interleave policy.
> > +   If more than one node is specified with the preferred policy, only the
> > +   lowest numeric id will be used.  Local policy will select the node where
> > +   the task is running at the time the nodes_allowed mask is constructed.
> > +
> > +3) For local policy to be deterministic, the task must be bound to a cpu or
> > +   cpus in a single node.  Otherwise, the task could be migrated to some
> > +   other node at any time after launch and the resulting node will be
> > +   indeterminate.  Thus, local policy is not very useful for this purpose.
> > +   Any of the other mempolicy modes may be used to specify a single node.
> > +
> > +4) The nodes allowed mask will be derived from any non-default task mempolicy,
> > +   whether this policy was set explicitly by the task itself or one of its
> > +   ancestors, such as numactl.  This means that if the task is invoked from a
> > +   shell with non-default policy, that policy will be used.  One can specify a
> > +   node list of "all" with numactl --interleave or --membind [-m] to achieve
> > +   interleaving over all nodes in the system or cpuset.
> > +
> 
> Nice description.
> 
> > +5) Any task mempolicy specifed--e.g., using numactl--will be constrained by
> > +   the resource limits of any cpuset in which the task runs.  Thus, there will
> > +   be no way for a task with non-default policy running in a cpuset with a
> > +   subset of the system nodes to allocate huge pages outside the cpuset
> > +   without first moving to a cpuset that contains all of the desired nodes.
> > +
> > +6) Hugepages allocated at boot time always use the node_online_map.
> 
> Implementation detail in the name, maybe just say "all online nodes with 
> memory"?

OK.  will fix for V6.  soon come, I hope.

> 
> > +
> > +
> > +Per Node Hugepages Attributes
> > +
> > +A subset of the contents of the root huge page control directory in sysfs,
> > +described above, has been replicated under each "node" system device in:
> > +
> > +	/sys/devices/system/node/node[0-9]*/hugepages/
> > +
> > +Under this directory, the subdirectory for each supported huge page size
> > +contains the following attribute files:
> > +
> > +	nr_hugepages
> > +	free_hugepages
> > +	surplus_hugepages
> > +
> > +The free_' and surplus_' attribute files are read-only.  They return the number
> > +of free and surplus [overcommitted] huge pages, respectively, on the parent
> > +node.
> > +
> > +The nr_hugepages attribute will return the total number of huge pages on the
> > +specified node.  When this attribute is written, the number of persistent huge
> > +pages on the parent node will be adjusted to the specified value, if sufficient
> > +resources exist, regardless of the task's mempolicy or cpuset constraints.
> > +
> > +Note that the number of overcommit and reserve pages remain global quantities,
> > +as we don't know until fault time, when the faulting task's mempolicy is applied,
> > +from which node the huge page allocation will be attempted.
> > +
> > +
> > +Using Huge Pages:
> > +
> >  If the user applications are going to request huge pages using mmap system
> >  call, then it is required that system administrator mount a file system of
> >  type hugetlbfs:
> > @@ -206,9 +301,11 @@ map_hugetlb.c.
> >   * requesting huge pages.
> >   *
> >   * For the ia64 architecture, the Linux kernel reserves Region number 4 for
> > - * huge pages.  That means the addresses starting with 0x800000... will need
> > - * to be specified.  Specifying a fixed address is not required on ppc64,
> > - * i386 or x86_64.
> > + * huge pages.  That means that if one requires a fixed address, a huge page
> > + * aligned address starting with 0x800000... will be required.  If a fixed
> > + * address is not required, the kernel will select an address in the proper
> > + * range.
> > + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
> >   *
> >   * Note: The default shared memory limit is quite low on many kernels,
> >   * you may need to increase it via:
> > @@ -237,14 +334,8 @@ map_hugetlb.c.
> >  
> >  #define dprintf(x)  printf(x)
> >  
> > -/* Only ia64 requires this */
> > -#ifdef __ia64__
> > -#define ADDR (void *)(0x8000000000000000UL)
> > -#define SHMAT_FLAGS (SHM_RND)
> > -#else
> > -#define ADDR (void *)(0x0UL)
> > +#define ADDR (void *)(0x0UL)	/* let kernel choose address */
> >  #define SHMAT_FLAGS (0)
> > -#endif
> >  
> >  int main(void)
> >  {
> > @@ -302,10 +393,12 @@ int main(void)
> >   * example, the app is requesting memory of size 256MB that is backed by
> >   * huge pages.
> >   *
> > - * For ia64 architecture, Linux kernel reserves Region number 4 for huge pages.
> > - * That means the addresses starting with 0x800000... will need to be
> > - * specified.  Specifying a fixed address is not required on ppc64, i386
> > - * or x86_64.
> > + * For the ia64 architecture, the Linux kernel reserves Region number 4 for
> > + * huge pages.  That means that if one requires a fixed address, a huge page
> > + * aligned address starting with 0x800000... will be required.  If a fixed
> > + * address is not required, the kernel will select an address in the proper
> > + * range.
> > + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
> >   */
> >  #include <stdlib.h>
> >  #include <stdio.h>
> > @@ -317,14 +410,8 @@ int main(void)
> >  #define LENGTH (256UL*1024*1024)
> >  #define PROTECTION (PROT_READ | PROT_WRITE)
> >  
> > -/* Only ia64 requires this */
> > -#ifdef __ia64__
> > -#define ADDR (void *)(0x8000000000000000UL)
> > -#define FLAGS (MAP_SHARED | MAP_FIXED)
> > -#else
> > -#define ADDR (void *)(0x0UL)
> > +#define ADDR (void *)(0x0UL)	/* let kernel choose address */
> >  #define FLAGS (MAP_SHARED)
> > -#endif
> >  
> >  void check_bytes(char *addr)
> >  {
> > 

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Thu, 3 Sep 2009 14:25:56 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com>
 <1252012158.6029.215.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Return-path: <owner-linux-mm@kvack.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252013163; bh=2gWFh4h4cCGRnB+ZSmD35BHtxNo=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=dMz7dhczPL/W0ua4b4XV3ZrwP1RgTrf
	e5lGMB55LAznPMXxqK4QKYKsZ8wwCmVcgj6EScnyLH3q+AR7i1HPLgw==
In-Reply-To: <1252012158.6029.215.camel@useless.americas.hpqcorp.net>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com, Randy Dunlap <randy.dunlap@oracle.com>

On Thu, 3 Sep 2009, Lee Schermerhorn wrote:

> > > @@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
> > >  /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
> > >  in the kernel.
> > >  
> > > -/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
> > > -pages in the kernel.  Super user can dynamically request more (or free some
> > > -pre-configured) huge pages.
> > > -The allocation (or deallocation) of hugetlb pages is possible only if there are
> > > -enough physically contiguous free pages in system (freeing of huge pages is
> > > -possible only if there are enough hugetlb pages free that can be transferred
> > > -back to regular memory pool).
> > > -
> > > -Pages that are used as hugetlb pages are reserved inside the kernel and cannot
> > > -be used for other purposes.
> > > -
> > > -Once the kernel with Hugetlb page support is built and running, a user can
> > > -use either the mmap system call or shared memory system calls to start using
> > > -the huge pages.  It is required that the system administrator preallocate
> > > -enough memory for huge page purposes.
> > > -
> > > -The administrator can preallocate huge pages on the kernel boot command line by
> > > -specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
> > > -requested.  This is the most reliable method for preallocating huge pages as
> > > -memory has not yet become fragmented.
> > > +/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
> > > +allocated in the kernel's huge page pool.  These are called "persistent"
> > > +huge pages.  A user with root privileges can dynamically allocate more or
> > > +free some persistent huge pages by increasing or decreasing the value of
> > > +'nr_hugepages'.
> > > +
> > 
> > So they're not necessarily "preallocated" then if they're already in use.
> 
> I don't see what in the text you're referring to"  "preallocated" vs
> "already in use" ???
> 

Your new line, "/proc/sys/vm/nr_hugepages indicates the current number of 
huge pages preallocated in the kernel's huge page pool" doesn't seem 
correct since pages are not "pre"-allocated if they are used by an 
application.  Preallocation is only when pages are allocated for a 
performance optimization in a later hotpath (such as in a slab allocator) 
or when the allocation cannot be done later in a non-blocking context.  If 
you were to remove "pre" from that line it would be clear.

> > Not sure if you need to spell out that they're called "huge page allowed 
> > nodes," isn't that an implementation detail?  The way Paul Jackson used to 
> > describe nodes_allowed is "set of allowable nodes," and I can't think of a 
> > better phrase.  That's also how the cpuset documentation describes them.
> 
> I wanted to refer to "huge pages allowed nodes" to differentiate from,
> e.g., cpusets mems_allowed"--i.e., I wanted the "huge pages" qualifier.
> I suppose I could introduce the phrase you suggest:  "set of allowable
> nodes" and emphasize that in this doc, it only refers to nodes from
> which persistent huge pages will be allocated.
> 

It's a different story if you want to use the phrase "allowed nodes" 
throughout this document to mean "the set of allowed nodes from which to 
allocate hugepages depending on the allocating task's mempolicy," but I 
didn't see any future reference to that phrase in your changes anyway.

> I understand.  However, I do think it's useful to support both a mask
> [and Mel prefers it be based on mempolicy] and per node attributes.  On
> some of our platforms, we do want explicit control over the placement of
> huge pages--e.g., for a data base shared area or such.  So, we can say,
> "I need <N> huge pages, and I want them on nodes 1, 3, 4 and 5", and
> then, assuming we start with no huge pages allocated [free them all if
> this is not the case]:
> 
> 	numactl -m 1,3-5 hugeadm --pool-pages-min 2M:<N>
> 
> Later, if I decide that maybe I want to adjust the number on node 1, I
> can:
> 
> 	numactl -m 1 --pool-pages-min 2M:{+|-}<count>
> 
> or:
> 
> 	echo <new-value> >/sys/devices/system/node/node1/hugepages/hugepages-2048KB/nr_hugepages
> 
> [Of course, I'd probably do this in a script to avoid all that typing :)]
> 

Yes, but the caveat I'm pointing out (and is really clearly described in 
your documentation changes here) is that existing applications, shell 
scripts, job schedulers, whatever, which currently free all system 
hugepages (or do so at a consistent interval down to the surplus 
value to reclaim memory) will now leak disjoint pages since the freeing is 
now governed by its mempolicy.  If the benefits of doing this 
significantly outweigh that potential for userspace breakage, I have no 
objection to it.  I just can't say for certain that it is.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with ESMTP id 7380F6B004F
	for <linux-mm@kvack.org>; Fri,  4 Sep 2009 10:30:51 -0400 (EDT)
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
In-Reply-To: <alpine.DEB.1.00.0909031350030.30662@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
	 <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
	 <1252010485.6029.180.camel@useless.americas.hpqcorp.net>
	 <alpine.DEB.1.00.0909031350030.30662@chino.kir.corp.google.com>
Content-Type: text/plain
Date: Fri, 04 Sep 2009 10:30:47 -0400
Message-Id: <1252074647.4389.46.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com
List-ID: <linux-mm.kvack.org>

On Thu, 2009-09-03 at 14:02 -0700, David Rientjes wrote:
> On Thu, 3 Sep 2009, Lee Schermerhorn wrote:
> 
> > > > @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
> > > >  		return;
> > > >  
> > > >  	for_each_hstate(h) {
> > > > -		err = hugetlb_sysfs_add_hstate(h);
> > > > +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> > > > +					 hstate_kobjs, &hstate_attr_group);
> > > >  		if (err)
> > > >  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
> > > >  								h->name);
> > > >  	}
> > > >  }
> > > >  
> > > > +#ifdef CONFIG_NUMA
> > > > +
> > > > +struct node_hstate {
> > > > +	struct kobject		*hugepages_kobj;
> > > > +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> > > > +};
> > > > +struct node_hstate node_hstates[MAX_NUMNODES];
> > > > +
> > > > +static struct attribute *per_node_hstate_attrs[] = {
> > > > +	&nr_hugepages_attr.attr,
> > > > +	&free_hugepages_attr.attr,
> > > > +	&surplus_hugepages_attr.attr,
> > > > +	NULL,
> > > > +};
> > > > +
> > > > +static struct attribute_group per_node_hstate_attr_group = {
> > > > +	.attrs = per_node_hstate_attrs,
> > > > +};
> > > > +
> > > > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> > > > +{
> > > > +	int nid;
> > > > +
> > > > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > > > +		struct node_hstate *nhs = &node_hstates[nid];
> > > > +		int i;
> > > > +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> > > > +			if (nhs->hstate_kobjs[i] == kobj) {
> > > > +				if (nidp)
> > > > +					*nidp = nid;
> > > > +				return &hstates[i];
> > > > +			}
> > > > +	}
> > > > +
> > > > +	BUG();
> > > > +	return NULL;
> > > > +}
> > > > +
> > > > +void hugetlb_unregister_node(struct node *node)
> > > > +{
> > > > +	struct hstate *h;
> > > > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > > > +
> > > > +	if (!nhs->hugepages_kobj)
> > > > +		return;
> > > > +
> > > > +	for_each_hstate(h)
> > > > +		if (nhs->hstate_kobjs[h - hstates]) {
> > > > +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> > > > +			nhs->hstate_kobjs[h - hstates] = NULL;
> > > > +		}
> > > > +
> > > > +	kobject_put(nhs->hugepages_kobj);
> > > > +	nhs->hugepages_kobj = NULL;
> > > > +}
> > > > +
> > > > +static void hugetlb_unregister_all_nodes(void)
> > > > +{
> > > > +	int nid;
> > > > +
> > > > +	for (nid = 0; nid < nr_node_ids; nid++)
> > > > +		hugetlb_unregister_node(&node_devices[nid]);
> > > > +
> > > > +	register_hugetlbfs_with_node(NULL, NULL);
> > > > +}
> > > > +
> > > > +void hugetlb_register_node(struct node *node)
> > > > +{
> > > > +	struct hstate *h;
> > > > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > > > +	int err;
> > > > +
> > > > +	if (nhs->hugepages_kobj)
> > > > +		return;		/* already allocated */
> > > > +
> > > > +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> > > > +							&node->sysdev.kobj);
> > > > +	if (!nhs->hugepages_kobj)
> > > > +		return;
> > > > +
> > > > +	for_each_hstate(h) {
> > > > +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> > > > +						nhs->hstate_kobjs,
> > > > +						&per_node_hstate_attr_group);
> > > > +		if (err) {
> > > > +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> > > > +					" for node %d\n",
> > > > +						h->name, node->sysdev.id);
> > > 
> > > Maybe add `err' to the printk so we know whether it was an -ENOMEM 
> > > condition or sysfs problem?
> > 
> > Just the raw negative number?
> > 
> 
> Sure.  I'm making the assumption that the printk is actually necessary in 
> the first place, which is rather unorthodox for functions that can 
> otherwise silently recover by unregistering the attribute.  Using the 
> printk implies you want to know about the failure, yet additional 
> debugging would be necessary to even identify what the failure was without 
> printing the errno.


David:  


I'm going to leave this printk as is.  I want to keep it, because the
global hstate function issues a similar printk [w/o] error code when it
can't add a global hstate.  The original authors considered this
necessary/useful, so I'm following suit.  The -ENOMEM error is returned
by hugetlb_sysfs_add_hstate() when kobject_create_and_add().  If the
kobject creation can fail for reasons other than ENOMEM, then showing
ENOMEM in the message will sometimes be bogus.  If it can only fail due
to lack of memory, then we are adding no additional info.

more below

> 
> > > 
> > > > +			hugetlb_unregister_node(node);
> > > > +			break;
> > > > +		}
> > > > +	}
> > > > +}
> > > > +
> > > > +static void hugetlb_register_all_nodes(void)
> > > > +{
> > > > +	int nid;
> > > > +
> > > > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > > 
> > > Don't you want to do this for all nodes in N_HIGH_MEMORY?  I don't think 
> > > we should be adding attributes for memoryless nodes.
> > 
> > 
> > Well, I wondered about that.  The persistent huge page allocation code
> > is careful to skip over nodes where it can't allow a huge page there,
> > whether or not the node has [any] memory.  So, it's safe to leave it
> > this way.
> 
> It's safe, but it seems inconsistent to allow hugepage attributes to 
> appear in /sys/devices/node/node* for nodes that have no memory.

OK.  I'm going to change this, and replace node_online_map with
node_state[N_HIGH_MEMORY] [or whatever] as a separate patch.  That way,
if someone complains that this doesn't work for memory hot plug, someone
who understands memory hotplut can fix it or we can drop that patch.

> 
> > And, I was worried about the interaction with memory hotplug,
> > as separate from node hotplug.  The current code handles node hot plug,
> > bug I wasn't sure about memory hot-plug within a node.
> 
> If memory hotplug doesn't update nodes_state[N_HIGH_MEMORY] then there are 
> plenty of other users that will currently fail as well.
> 
> > I.e., would the
> > node driver get called to register the attributes in this case?
> 
> Not without a MEM_ONLINE notifier.

That's what I thought.  I'm not up to speed on that area, and have no
bandwidth nor interest to go there, right now.  If you think that's a
show stopper for per node attributes, we can defer this part of the
series.  But, I'd prefer to stick with current "no-op" attributes for
memoryless nodes over that alternative.

> 
> > Maybe
> > that case doesn't exist, so I don't have to worry about it.   I think
> > this is somewhat similar to the top cpuset mems_allowed being set to all
> > possible to cover any subsequently added nodes/memory.
> > 
> 
> That's because the page allocator's zonelists won't try to allocate from a 
> memoryless node and the only hook into the cpuset code in that path is to 
> check whether a nid is set in cpuset_current_mems_allowed.  It's quite 
> different from providing per-node allocation and freeing mechanisms for 
> pages on nodes without memory like this approach.

OK, we have different perspectives on this.  I'm not at all offended by
the no-op attributes.  If you're worried about safety, I can check
explicitly in the attribute handlers and bail out early for memoryless
nodes.  Then, should someone hot add memory to the node, it will start
attemping to allocate huge pages when requested.

> 


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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
 mempolicy based management.
Date: Fri, 04 Sep 2009 11:23:03 -0400
Message-ID: <1252077783.4389.54.camel@useless.americas.hpqcorp.net>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
	 <20090903134210.5a27611d.randy.dunlap@oracle.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <owner-linux-mm@kvack.org>
In-Reply-To: <20090903134210.5a27611d.randy.dunlap@oracle.com>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Thu, 2009-09-03 at 13:42 -0700, Randy Dunlap wrote:
> On Fri, 28 Aug 2009 12:03:51 -0400 Lee Schermerhorn wrote:
> 
> (Thanks for cc:, David.)

Randy:  thanks for the review.  I'll add you to the cc list for
reposting of the series.  I'll make all of the changes you suggest,
except those that you seemed to concede might not be required:

1) surplus vs overcommitted.  The currently exported user space
interface uses both "overcommit" for specifying the limit and "surplus"
for displaying the number of overcommitted pages in use.  I agree that
it's somewhat of a misuse of "surplus" as the count actually indicates
"deficit spending" of huge page resources.

2)  the s/cpu/CPU/.  As you say, that cat is on the run.

<snip>

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19])
	by kanga.kvack.org (Postfix) with ESMTP id 014E16B007E
	for <linux-mm@kvack.org>; Tue,  8 Sep 2009 06:44:05 -0400 (EDT)
Date: Tue, 8 Sep 2009 11:44:09 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Message-ID: <20090908104409.GB28127@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Thu, Sep 03, 2009 at 02:25:56PM -0700, David Rientjes wrote:
> On Thu, 3 Sep 2009, Lee Schermerhorn wrote:
> 
> > > > @@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
> > > >  /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
> > > >  in the kernel.
> > > >  
> > > > -/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
> > > > -pages in the kernel.  Super user can dynamically request more (or free some
> > > > -pre-configured) huge pages.
> > > > -The allocation (or deallocation) of hugetlb pages is possible only if there are
> > > > -enough physically contiguous free pages in system (freeing of huge pages is
> > > > -possible only if there are enough hugetlb pages free that can be transferred
> > > > -back to regular memory pool).
> > > > -
> > > > -Pages that are used as hugetlb pages are reserved inside the kernel and cannot
> > > > -be used for other purposes.
> > > > -
> > > > -Once the kernel with Hugetlb page support is built and running, a user can
> > > > -use either the mmap system call or shared memory system calls to start using
> > > > -the huge pages.  It is required that the system administrator preallocate
> > > > -enough memory for huge page purposes.
> > > > -
> > > > -The administrator can preallocate huge pages on the kernel boot command line by
> > > > -specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
> > > > -requested.  This is the most reliable method for preallocating huge pages as
> > > > -memory has not yet become fragmented.
> > > > +/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
> > > > +allocated in the kernel's huge page pool.  These are called "persistent"
> > > > +huge pages.  A user with root privileges can dynamically allocate more or
> > > > +free some persistent huge pages by increasing or decreasing the value of
> > > > +'nr_hugepages'.
> > > > +
> > > 
> > > So they're not necessarily "preallocated" then if they're already in use.
> > 
> > I don't see what in the text you're referring to"  "preallocated" vs
> > "already in use" ???
> > 
> 
> Your new line, "/proc/sys/vm/nr_hugepages indicates the current number of 
> huge pages preallocated in the kernel's huge page pool" doesn't seem 
> correct since pages are not "pre"-allocated if they are used by an 
> application.  Preallocation is only when pages are allocated for a 
> performance optimization in a later hotpath (such as in a slab allocator) 
> or when the allocation cannot be done later in a non-blocking context.  If 
> you were to remove "pre" from that line it would be clear.
> 
> > > Not sure if you need to spell out that they're called "huge page allowed 
> > > nodes," isn't that an implementation detail?  The way Paul Jackson used to 
> > > describe nodes_allowed is "set of allowable nodes," and I can't think of a 
> > > better phrase.  That's also how the cpuset documentation describes them.
> > 
> > I wanted to refer to "huge pages allowed nodes" to differentiate from,
> > e.g., cpusets mems_allowed"--i.e., I wanted the "huge pages" qualifier.
> > I suppose I could introduce the phrase you suggest:  "set of allowable
> > nodes" and emphasize that in this doc, it only refers to nodes from
> > which persistent huge pages will be allocated.
> > 
> 
> It's a different story if you want to use the phrase "allowed nodes" 
> throughout this document to mean "the set of allowed nodes from which to 
> allocate hugepages depending on the allocating task's mempolicy," but I 
> didn't see any future reference to that phrase in your changes anyway.
> 
> > I understand.  However, I do think it's useful to support both a mask
> > [and Mel prefers it be based on mempolicy] and per node attributes.  On
> > some of our platforms, we do want explicit control over the placement of
> > huge pages--e.g., for a data base shared area or such.  So, we can say,
> > "I need <N> huge pages, and I want them on nodes 1, 3, 4 and 5", and
> > then, assuming we start with no huge pages allocated [free them all if
> > this is not the case]:
> > 
> > 	numactl -m 1,3-5 hugeadm --pool-pages-min 2M:<N>
> > 
> > Later, if I decide that maybe I want to adjust the number on node 1, I
> > can:
> > 
> > 	numactl -m 1 --pool-pages-min 2M:{+|-}<count>
> > 
> > or:
> > 
> > 	echo <new-value> >/sys/devices/system/node/node1/hugepages/hugepages-2048KB/nr_hugepages
> > 
> > [Of course, I'd probably do this in a script to avoid all that typing :)]
> > 
> 
> Yes, but the caveat I'm pointing out (and is really clearly described in 
> your documentation changes here) is that existing applications, shell 
> scripts, job schedulers, whatever, which currently free all system 
> hugepages (or do so at a consistent interval down to the surplus 
> value to reclaim memory) will now leak disjoint pages since the freeing is 
> now governed by its mempolicy. 

While this is a possibility, it makes little sense to assume that behaviour. To
be really bitten by the change, the policy used to allocate huge pages needs
to be different than the policy used to free them. This would be a bit
screwy as it would imply the job scheduler allocated pages that would
then be unusable by the job if policies were being obeyed which makes
very little sense.

> If the benefits of doing this 
> significantly outweigh that potential for userspace breakage, I have no 
> objection to it.  I just can't say for certain that it is.
> 

An application depending on memory policies to be ignored is pretty broken
to begin with.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Tue, 8 Sep 2009 12:51:48 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net>
 <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie>
Mime-Version: 1.0
Return-path: <owner-linux-mm@kvack.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252439515; bh=BnUujHuwet23K76WyS06Z+8VOX0=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=i50owx+AbCxMZVXFdpnaqbpV4O3dEwD
	zajI7RcwidmEBQ4W0b/SIwE3zkWbAHlJ0kAivPnPaY0kVqw3Y3G54ew==
In-Reply-To: <20090908104409.GB28127@csn.ul.ie>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Tue, 8 Sep 2009, Mel Gorman wrote:

> > Yes, but the caveat I'm pointing out (and is really clearly described in 
> > your documentation changes here) is that existing applications, shell 
> > scripts, job schedulers, whatever, which currently free all system 
> > hugepages (or do so at a consistent interval down to the surplus 
> > value to reclaim memory) will now leak disjoint pages since the freeing is 
> > now governed by its mempolicy. 
> 
> While this is a possibility, it makes little sense to assume that behaviour. To
> be really bitten by the change, the policy used to allocate huge pages needs
> to be different than the policy used to free them. This would be a bit
> screwy as it would imply the job scheduler allocated pages that would
> then be unusable by the job if policies were being obeyed which makes
> very little sense.
> 

Au contraire, the hugepages= kernel parameter is not restricted to any 
mempolicy.

> > If the benefits of doing this 
> > significantly outweigh that potential for userspace breakage, I have no 
> > objection to it.  I just can't say for certain that it is.
> > 
> 
> An application depending on memory policies to be ignored is pretty broken
> to begin with.
> 

Theoretically, yes, but not in practice.  /proc/sys/vm/nr_hugepages has 
always allocated and freed with disregard to current's mempolicy prior to 
this patchset and it wouldn't be "broken" for an application to assume 
that it will continue to do so.  More broken is assuming that such an 
application should have been written to change its mempolicy to include 
all nodes that have hugepages prior to freeing because someday the kernel 
would change to do mempolicy-restricted hugepage freeing.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3])
	by kanga.kvack.org (Postfix) with ESMTP id 3165F6B007E
	for <linux-mm@kvack.org>; Tue,  8 Sep 2009 16:04:51 -0400 (EDT)
Date: Tue, 8 Sep 2009 21:04:51 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Message-ID: <20090908200451.GA6481@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Tue, Sep 08, 2009 at 12:51:48PM -0700, David Rientjes wrote:
> On Tue, 8 Sep 2009, Mel Gorman wrote:
> 
> > > Yes, but the caveat I'm pointing out (and is really clearly described in 
> > > your documentation changes here) is that existing applications, shell 
> > > scripts, job schedulers, whatever, which currently free all system 
> > > hugepages (or do so at a consistent interval down to the surplus 
> > > value to reclaim memory) will now leak disjoint pages since the freeing is 
> > > now governed by its mempolicy. 
> > 
> > While this is a possibility, it makes little sense to assume that behaviour. To
> > be really bitten by the change, the policy used to allocate huge pages needs
> > to be different than the policy used to free them. This would be a bit
> > screwy as it would imply the job scheduler allocated pages that would
> > then be unusable by the job if policies were being obeyed which makes
> > very little sense.
> > 
> 
> Au contraire, the hugepages= kernel parameter is not restricted to any 
> mempolicy.
> 

I'm not seeing how it would be considered symmetric to compare allocation
at a boot-time parameter with freeing happening at run-time within a mempolicy.
It's more plausible to me that such a scenario will having the freeing
thread either with no policy or the ability to run with no policy
applied.

> > > If the benefits of doing this 
> > > significantly outweigh that potential for userspace breakage, I have no 
> > > objection to it.  I just can't say for certain that it is.
> > > 
> > 
> > An application depending on memory policies to be ignored is pretty broken
> > to begin with.
> > 
> 
> Theoretically, yes, but not in practice.  /proc/sys/vm/nr_hugepages has 
> always allocated and freed with disregard to current's mempolicy prior to 
> this patchset and it wouldn't be "broken" for an application to assume 
> that it will continue to do so. 

I don't think we're going to agree on this one. I find it very unlikely
that the process doing the allocation and freeing is going to have
different memory policies.

> More broken is assuming that such an 
> application should have been written to change its mempolicy to include 
> all nodes that have hugepages prior to freeing because someday the kernel 
> would change to do mempolicy-restricted hugepage freeing.
> 

It wouldn't have to be rewritten. At very worst, rearranged at startup
to have the same policy when allocating and freeing.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Tue, 8 Sep 2009 13:18:01 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net>
 <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie>
Mime-Version: 1.0
Return-path: <owner-linux-mm@kvack.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252441089; bh=ojI/q0IeTviC/h/J3cgwN0gn6vg=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=fbkGhVcDMPNwv/o5yltTmX95p6yQABY
	XsULeRzxyoOyiLJ1CWIi+LaVzCSMCWqmkHKKVPpTUUQ4ALI9nOlUV6g==
In-Reply-To: <20090908200451.GA6481@csn.ul.ie>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Tue, 8 Sep 2009, Mel Gorman wrote:

> > Au contraire, the hugepages= kernel parameter is not restricted to any 
> > mempolicy.
> > 
> 
> I'm not seeing how it would be considered symmetric to compare allocation
> at a boot-time parameter with freeing happening at run-time within a mempolicy.
> It's more plausible to me that such a scenario will having the freeing
> thread either with no policy or the ability to run with no policy
> applied.
> 

Imagine a cluster of machines that are all treated equally to serve a 
variety of different production jobs.  One of those production jobs 
requires a very high percentage of hugepages.  In fact, its performance 
gain is directly proportional to the number of hugepages allocated.

It is quite plausible for all machines to be booted with hugepages= to 
achieve the maximum number of hugepages that those machines may support.  
Depending on what jobs they will serve, however, those hugepages may 
immediately be freed (or a subset, depending on other smaller jobs that 
may want them.)  If the job scheduler is bound to a mempolicy which does 
not include all nodes with memory, those hugepages are now leaked.  That 
was not the behavior over the past three or four years until this 
patchset.

That example is not dealing in hypotheticals or assumptions on how people 
use hugepages, it's based on reality.  As I said previously, I don't 
necessarily have an objection to that if it can be shown that the 
advantages significantly outweigh the disadvantages.  I'm not sure I see 
the advantage in being implict vs. explicit, however.  Mempolicy 
allocation and freeing is now _implicit_ because its restricted to 
current's mempolicy when it wasn't before, yet node-targeted hugepage 
allocation and freeing is _explicit_ because it's a new interface and on 
the same granularity.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35])
	by kanga.kvack.org (Postfix) with ESMTP id D5EF46B007E
	for <linux-mm@kvack.org>; Tue,  8 Sep 2009 17:41:07 -0400 (EDT)
Date: Tue, 8 Sep 2009 22:41:10 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Message-ID: <20090908214109.GB6481@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Tue, Sep 08, 2009 at 01:18:01PM -0700, David Rientjes wrote:
> On Tue, 8 Sep 2009, Mel Gorman wrote:
> 
> > > Au contraire, the hugepages= kernel parameter is not restricted to any 
> > > mempolicy.
> > > 
> > 
> > I'm not seeing how it would be considered symmetric to compare allocation
> > at a boot-time parameter with freeing happening at run-time within a mempolicy.
> > It's more plausible to me that such a scenario will having the freeing
> > thread either with no policy or the ability to run with no policy
> > applied.
> > 
> 
> Imagine a cluster of machines that are all treated equally to serve a 
> variety of different production jobs.  One of those production jobs 
> requires a very high percentage of hugepages.  In fact, its performance 
> gain is directly proportional to the number of hugepages allocated.
> 
> It is quite plausible for all machines to be booted with hugepages= to 
> achieve the maximum number of hugepages that those machines may support.  
> Depending on what jobs they will serve, however, those hugepages may 
> immediately be freed (or a subset, depending on other smaller jobs that 
> may want them.)  If the job scheduler is bound to a mempolicy which does 
> not include all nodes with memory, those hugepages are now leaked. 

Why is a job scheduler that is expecting to affect memory on a global
basis running inside a mempolicy that restricts it to a subset of nodes?
It seems inconsistent that an isolated job starting could affect the global
state potentially affecting other jobs starting up.

In addition, if it is the case that the jobs performance is directly
proportional to the number of hugepages it gets access to, why is it starting
up with access to only a subset of the available hugepages? Why is it not
being setup to being the first job to start on a freshly booting machine,
starting on the subset of nodes allowed and requesting the maximum number
of hugepages it needs such that it achieves maximum performance? With the
memory policy approach, it's very straight-forward to do this because all
it has to do is write to nr_hugepages when it starts-up.

> That 
> was not the behavior over the past three or four years until this 
> patchset.
> 

While this is true, I know people have also been bitten by the expectation
that writing to nr_hugepages would obey a memory policy and were surprised
when it didn't happen and sent me whinging emails. It also appeared obvious
to me that it's how the interface should behave even if it wasn't doing it
in practice. Once nr_hugepages obeys memory policies, it's fairly convenient
to size the number of pages on a subset of nodes using numactl - a tool that
people would generally expect to be used when operating on nodes. Hence the
example usage being

numactl -m x,y,z hugeadm --pool-pages-min $PAGESIZE:$NUMPAGES

> That example is not dealing in hypotheticals or assumptions on how people 
> use hugepages, it's based on reality.  As I said previously, I don't 
> necessarily have an objection to that if it can be shown that the 
> advantages significantly outweigh the disadvantages.  I'm not sure I see 
> the advantage in being implict vs. explicit, however. 

The advantage is that with memory policies on nr_hugepages, it's very
convenient to allocate pages within a subset of nodes without worrying about
where exactly those huge pages are being allocated from. It will allocate
them on a round-robin basis allocating more pages on one node over another
if fragmentation requires it rather than shifting the burden to a userspace
application figuring out what nodes might succeed an allocation or shifting
the burden onto the system administrator. It's likely that writing to the
global nr_hugepages within a mempolicy will end up with a more sensible
result than a userspace application dealing with the individual node-specific
nr_hugepages files.

To do the same with the explicit interface, a userspace application
or administrator would have to keep reading the existing nr_hugepages,
writing existing_nr_hugepages+1 to each node in the allowed set, re-reading
to check for allocating failure and round-robining by hand.  This seems
awkward-for-the-sake-of-being-awkward when the kernel is already prefectly
aware of how to round-robin allocate the requested number of nodes allocating
more on one node if necessary.

> Mempolicy 
> allocation and freeing is now _implicit_ because its restricted to 
> current's mempolicy when it wasn't before, yet node-targeted hugepage 
> allocation and freeing is _explicit_ because it's a new interface and on 
> the same granularity.
> 

Arguably because the application was restricted by a memory policy, it
should not be able to operating outside of that policy and be forbidden
from writing to per-node-nr_hugepages outside the allowed set.  However,
that would appear awkward for the sake of it.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Tue, 8 Sep 2009 15:54:40 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net>
 <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com>
 <20090908214109.GB6481@csn.ul.ie>
Mime-Version: 1.0
Return-path: <owner-linux-mm@kvack.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252450485; bh=aTGJ29QpE7fZd6iuv892io0hNU0=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=SGQas9F2juqsYzZyPt/WpdKhWpXfjLi
	3yqcsQF/DHjsjj+rmjje7b1xrdUa3LkFQa6h1tE2+z4tYiRB7rzZDXQ==
In-Reply-To: <20090908214109.GB6481@csn.ul.ie>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Tue, 8 Sep 2009, Mel Gorman wrote:

> Why is a job scheduler that is expecting to affect memory on a global
> basis running inside a mempolicy that restricts it to a subset of nodes?

Because hugepage allocation and freeing has always been on a global basis, 
there was no previous restriction.

> In addition, if it is the case that the jobs performance is directly
> proportional to the number of hugepages it gets access to, why is it starting
> up with access to only a subset of the available hugepages?

It's not, that particular job is allocated the entire machine other than 
the job scheduler.  The point is that the machine pool treats each machine 
equally so while they are all booted with hugepages=<large number>, 
machines that don't serve this application immediately free them.  If 
hugepages cannot be dynamically allocated up to a certain threshold that 
the application requires, a reboot is necessary if no other machines are 
available.

Since the only way to achieve the absolute maximum number of hugepages 
possible on a machine is through the command line, it's completely 
reasonable to use it on every boot and then subsequently free them when 
they're unnecessary.

> Why is it not
> being setup to being the first job to start on a freshly booting machine,
> starting on the subset of nodes allowed and requesting the maximum number
> of hugepages it needs such that it achieves maximum performance? With the
> memory policy approach, it's very straight-forward to do this because all
> it has to do is write to nr_hugepages when it starts-up.
> 

The job scheduler will always be the first job to start on the machine and 
it may have a mempolicy of its own.  When it attempts to free all 
hugepages allocated by the command line, it will then leak pages because 
of these changes.

Arguing that applications should always dynamically allocate their 
hugepages on their own subset of nodes when they are started is wishful 
thinking: it's much easier to allocate as many as possible on the command 
line and then free unnecessary hugepages than allocate on the mempolicy's 
nodes for the maximal number of hugepages.

> > That 
> > was not the behavior over the past three or four years until this 
> > patchset.
> > 
> 
> While this is true, I know people have also been bitten by the expectation
> that writing to nr_hugepages would obey a memory policy and were surprised
> when it didn't happen and sent me whinging emails.

Ok, but I doubt the inverse is true: people probably haven't emailed you 
letting you know that they've coded their application for hugepage 
allocations based on how the kernel has implemented it for years, so 
there's no context.  That's the population that I'm worried about (and is 
also solved by node-targeted hugepage allocation, btw).

 [ Such users who have emailed you could always use cpusets for the
   desired effect, it's not like there isn't a solution. ]

> It also appeared obvious
> to me that it's how the interface should behave even if it wasn't doing it
> in practice. Once nr_hugepages obeys memory policies, it's fairly convenient
> to size the number of pages on a subset of nodes using numactl - a tool that
> people would generally expect to be used when operating on nodes. Hence the
> example usage being
> 
> numactl -m x,y,z hugeadm --pool-pages-min $PAGESIZE:$NUMPAGES
> 

We need a new mempolicy flag, then, such as MPOL_F_HUGEPAGES to constrain 
hugepage allocation and freeing via the global tunable to such a 
mempolicy.

> The advantage is that with memory policies on nr_hugepages, it's very
> convenient to allocate pages within a subset of nodes without worrying about
> where exactly those huge pages are being allocated from. It will allocate
> them on a round-robin basis allocating more pages on one node over another
> if fragmentation requires it rather than shifting the burden to a userspace
> application figuring out what nodes might succeed an allocation or shifting
> the burden onto the system administrator.

That "burden" is usually for good reason: if my MPOL_INTERLEAVE policy 
gets hugepages that are relatively unbalanced across a set of nodes that I 
arbitrarily picked, my interleave it's going to be nearly as optimized 
compared to what userspace can allocate with the node-targeted approach: 
allocate [desired nr of hugepages] / [nr nodes in policy] hugepages via 
/sys/devices/system/node/node*/nr_hugepages, and construct a policy out of 
the nodes that give a true interleave.  That's not a trivial performance 
gain and can rarely be dismissed by simply picking an arbitrary set.

> It's likely that writing to the
> global nr_hugepages within a mempolicy will end up with a more sensible
> result than a userspace application dealing with the individual node-specific
> nr_hugepages files.
> 

Disagree for the interleave example above without complex userspace logic 
to determine how successful hugepage allocation will be based on 
fragmentation.

> To do the same with the explicit interface, a userspace application
> or administrator would have to keep reading the existing nr_hugepages,
> writing existing_nr_hugepages+1 to each node in the allowed set, re-reading
> to check for allocating failure and round-robining by hand.  This seems
> awkward-for-the-sake-of-being-awkward when the kernel is already prefectly
> aware of how to round-robin allocate the requested number of nodes allocating
> more on one node if necessary.
> 

No need for an iteration, simply allocate the ratio I specified above on 
each node and then construct a mempolicy from those nodes based on actual 
results instead of arbitrarily.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19])
	by kanga.kvack.org (Postfix) with ESMTP id 407766B007E
	for <linux-mm@kvack.org>; Wed,  9 Sep 2009 04:16:26 -0400 (EDT)
Date: Wed, 9 Sep 2009 09:16:31 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Message-ID: <20090909081631.GB24614@csn.ul.ie>
References: <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Tue, Sep 08, 2009 at 03:54:40PM -0700, David Rientjes wrote:
> On Tue, 8 Sep 2009, Mel Gorman wrote:
> 
> > Why is a job scheduler that is expecting to affect memory on a global
> > basis running inside a mempolicy that restricts it to a subset of nodes?
> 
> Because hugepage allocation and freeing has always been on a global basis, 
> there was no previous restriction.
> 

And to beat a dead horse, it does make sense that an application
allocating hugepages obey memory policies. It does with dynamic hugepage
resizing for example. It should have been done years ago and
unfortunately wasn't but it's not the first time that the behaviour of
hugepages differed from the core VM.

> > In addition, if it is the case that the jobs performance is directly
> > proportional to the number of hugepages it gets access to, why is it starting
> > up with access to only a subset of the available hugepages?
> 
> It's not, that particular job is allocated the entire machine other than 
> the job scheduler. The point is that the machine pool treats each machine 
> equally so while they are all booted with hugepages=<large number>, 
> machines that don't serve this application immediately free them.  If 
> hugepages cannot be dynamically allocated up to a certain threshold that 
> the application requires, a reboot is necessary if no other machines are 
> available.
> 
> Since the only way to achieve the absolute maximum number of hugepages 
> possible on a machine is through the command line, it's completely 
> reasonable to use it on every boot and then subsequently free them when 
> they're unnecessary.
> 

But less reasonable that an application within a memory policy be able
to affect memory on a global basis. Why not let it break cpusets or
something else as well?

> > Why is it not
> > being setup to being the first job to start on a freshly booting machine,
> > starting on the subset of nodes allowed and requesting the maximum number
> > of hugepages it needs such that it achieves maximum performance? With the
> > memory policy approach, it's very straight-forward to do this because all
> > it has to do is write to nr_hugepages when it starts-up.
> > 
> 
> The job scheduler will always be the first job to start on the machine and 
> it may have a mempolicy of its own.  When it attempts to free all 
> hugepages allocated by the command line, it will then leak pages because 
> of these changes.
> 
> Arguing that applications should always dynamically allocate their 
> hugepages on their own subset of nodes when they are started is wishful 
> thinking: it's much easier to allocate as many as possible on the command 
> line and then free unnecessary hugepages than allocate on the mempolicy's 
> nodes for the maximal number of hugepages.
> 

Only in your particular case where you're willing to reboot the machine to
satisfy a jobs hugepage requirement. This is not always the situation. On
shared-machines, there can be many jobs running, each with different hugepage
requirements. The objective of things like anti-fragmentation, lumpy reclaim
and the like was to allow these sort of jobs to allocate the pages they
need at run-time. In the event these jobs are running on a subset of nodes,
it's of benefit to have nr_hugepages obey memory policies or else userspace
or the administrator has to try a number of different tricks to get the
hugepages they need on the nodes they want.

> > > That 
> > > was not the behavior over the past three or four years until this 
> > > patchset.
> > > 
> > 
> > While this is true, I know people have also been bitten by the expectation
> > that writing to nr_hugepages would obey a memory policy and were surprised
> > when it didn't happen and sent me whinging emails.
> 
> Ok, but I doubt the inverse is true: people probably haven't emailed you 
> letting you know that they've coded their application for hugepage 
> allocations based on how the kernel has implemented it for years, so 
> there's no context. 

They didn't code their application specifically to this case. What happened
is that their jobs needed to run on a subset of nodes and they wanted the
hugepages only available on those nodes. They wrote the value under a memory
policy to nr_hugepages and were suprised when that didn't work. cpusets were
not an obvious choice.

> That's the population that I'm worried about (and is 
> also solved by node-targeted hugepage allocation, btw).
> 

I disagree because it pushes the burden of interleaving to the userspace
application or the administrator, something the kernel can and is able
to deal with.

>  [ Such users who have emailed you could always use cpusets for the
>    desired effect, it's not like there isn't a solution. ]
>  

Which is very convulated. numactl is the expected administrative interface
to restrict allocations on a set of nodes, not cpusets.

> > It also appeared obvious
> > to me that it's how the interface should behave even if it wasn't doing it
> > in practice. Once nr_hugepages obeys memory policies, it's fairly convenient
> > to size the number of pages on a subset of nodes using numactl - a tool that
> > people would generally expect to be used when operating on nodes. Hence the
> > example usage being
> > 
> > numactl -m x,y,z hugeadm --pool-pages-min $PAGESIZE:$NUMPAGES
> > 
> 
> We need a new mempolicy flag, then, such as MPOL_F_HUGEPAGES to constrain 
> hugepage allocation and freeing via the global tunable to such a 
> mempolicy.
> 

This would be somewhat inconsistent. When dynamic hugepage pool resizing
is enabled, the application obeys the memory policy that is in place.
Your suggested policy would only apply when nr_hugepages is being
written to.

It would also appear as duplicated and redundant functionality to numactl
because it would have --interleave meaning interleaving and --hugepages
meaning interleave but only when nr_hugepages is being written to.

> > The advantage is that with memory policies on nr_hugepages, it's very
> > convenient to allocate pages within a subset of nodes without worrying about
> > where exactly those huge pages are being allocated from. It will allocate
> > them on a round-robin basis allocating more pages on one node over another
> > if fragmentation requires it rather than shifting the burden to a userspace
> > application figuring out what nodes might succeed an allocation or shifting
> > the burden onto the system administrator.
> 
> That "burden" is usually for good reason: if my MPOL_INTERLEAVE policy 
> gets hugepages that are relatively unbalanced across a set of nodes that I 
> arbitrarily picked, my interleave it's going to be nearly as optimized 
> compared to what userspace can allocate with the node-targeted approach: 
> allocate [desired nr of hugepages] / [nr nodes in policy] hugepages via 
> /sys/devices/system/node/node*/nr_hugepages, and construct a policy out of 
> the nodes that give a true interleave.

Except that knowledge and awareness of having to do this is pushed out
to userspace and the system administrator, when again it's something
the kernel can trivially do on their behalf.

> That's not a trivial performance 
> gain and can rarely be dismissed by simply picking an arbitrary set.
> 
> > It's likely that writing to the
> > global nr_hugepages within a mempolicy will end up with a more sensible
> > result than a userspace application dealing with the individual node-specific
> > nr_hugepages files.
> > 
> 
> Disagree for the interleave example above without complex userspace logic 
> to determine how successful hugepage allocation will be based on 
> fragmentation.
> 

It can read the value back for nr_hugepages to see was the total number
of allocation successful. hugeadm does this for example and warns when the
desired number of pages were not allocated (or not freed for that example). It
would not detect if the memory allocations were imbalanced without taking
further steps but it would depend on whether being evenly interleaved was
more important than having the maximum number of hugepages.

> > To do the same with the explicit interface, a userspace application
> > or administrator would have to keep reading the existing nr_hugepages,
> > writing existing_nr_hugepages+1 to each node in the allowed set, re-reading
> > to check for allocating failure and round-robining by hand.  This seems
> > awkward-for-the-sake-of-being-awkward when the kernel is already prefectly
> > aware of how to round-robin allocate the requested number of nodes allocating
> > more on one node if necessary.
> > 
> 
> No need for an iteration, simply allocate the ratio I specified above on 
> each node and then construct a mempolicy from those nodes based on actual 
> results instead of arbitrarily.
> 

They would still need to read back the values, determine if the full
allocation was successful and if not, figure out where it failed and
recalculate. 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Wed, 9 Sep 2009 13:44:28 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com>
References: <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com>
 <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie>
 <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie>
Mime-Version: 1.0
Return-path: <owner-linux-mm@kvack.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252529077; bh=aIQpkK6qTt4qqWvkzcpbriRTEok=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=f4gatiz1sYNYkik+lx8Xm1r+jO+MqMi
	k/0Btcs1HBPxXlxMtzgcpXeC9f0nWmaFHTmsLCiz3GUogg0dQnmipCg==
In-Reply-To: <20090909081631.GB24614@csn.ul.ie>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Wed, 9 Sep 2009, Mel Gorman wrote:

> And to beat a dead horse, it does make sense that an application
> allocating hugepages obey memory policies. It does with dynamic hugepage
> resizing for example. It should have been done years ago and
> unfortunately wasn't but it's not the first time that the behaviour of
> hugepages differed from the core VM.
> 

I agree completely, I'm certainly not defending the current implementation 
as a sound design and I too would have preferred that it have done the 
same as Lee's patchset from the very beginning.  The issue I'm raising is 
that while we both agree the current behavior is suboptimal and confusing, 
it is the long-standing kernel behavior.  There are applications out there 
that are written to allocate and free hugepages and now changing the pool 
from which they can allocate or free to could be problematic.

I'm personally fine with the breakage since I'm aware of this discussion 
and can easily fix it in userspace.  I'm more concerned about others 
leaking hugepages or having their boot scripts break because they are 
allocating far fewer hugepages than before.  The documentation 
(Documentation/vm/hugetlbpage.txt) has always said 
/proc/sys/vm/nr_hugepaegs affects hugepages on a system level and now that 
it's changed, I think it should be done explicitly with a new flag than 
implicitly.

Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
and only using the new behavior when this is set would be inconsistent or 
inadvisible?  Since this is a new behavior that will differ from the 
long-standing default, it seems like it warrants a new mempolicy flag to 
avoid all userspace breakage and make hugepage allocation and freeing with 
an underlying mempolicy explicit.

This would address your audience that have been (privately) emailing you 
while confused about why the hugepages being allocated from a global 
tunable wouldn't be confined to their mempolicy.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51])
	by kanga.kvack.org (Postfix) with ESMTP id 3581F6B004D
	for <linux-mm@kvack.org>; Thu, 10 Sep 2009 08:26:38 -0400 (EDT)
Date: Thu, 10 Sep 2009 13:26:42 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Message-ID: <20090910122641.GA31153@csn.ul.ie>
References: <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Wed, Sep 09, 2009 at 01:44:28PM -0700, David Rientjes wrote:
> On Wed, 9 Sep 2009, Mel Gorman wrote:
> 
> > And to beat a dead horse, it does make sense that an application
> > allocating hugepages obey memory policies. It does with dynamic hugepage
> > resizing for example. It should have been done years ago and
> > unfortunately wasn't but it's not the first time that the behaviour of
> > hugepages differed from the core VM.
> > 
> 
> I agree completely, I'm certainly not defending the current implementation 
> as a sound design and I too would have preferred that it have done the 
> same as Lee's patchset from the very beginning.  The issue I'm raising is 
> that while we both agree the current behavior is suboptimal and confusing, 
> it is the long-standing kernel behavior.  There are applications out there 
> that are written to allocate and free hugepages and now changing the pool 
> from which they can allocate or free to could be problematic.
> 

While I doubt there are many, the counter-example of one is not
something I can wish or wave away.

> I'm personally fine with the breakage since I'm aware of this discussion 
> and can easily fix it in userspace.  I'm more concerned about others 
> leaking hugepages or having their boot scripts break because they are 
> allocating far fewer hugepages than before. 

I just find it very improbably that system-wide maintenance or boot-up
processes are running within restricted environments that then expect to
have system-wide capabilities but it wouldn't be the first time something
unusual was implemented.

> The documentation 
> (Documentation/vm/hugetlbpage.txt) has always said 
> /proc/sys/vm/nr_hugepaegs affects hugepages on a system level and now that 
> it's changed, I think it should be done explicitly with a new flag than 
> implicitly.
> 
> Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
> and only using the new behavior when this is set would be inconsistent or 
> inadvisible?

I already explained this. The interface in numactl would look weird. There
would be an --interleave switch and a --hugepages-interleave that only
applies to nr_hugepages. The smarts could be in hugeadm to apply the mask
when --pool-pages-min is specified but that wouldn't help scripts that are
still using echo.

> Since this is a new behavior that will differ from the 
> long-standing default, it seems like it warrants a new mempolicy flag to 
> avoid all userspace breakage and make hugepage allocation and freeing with 
> an underlying mempolicy explicit.
> 
> This would address your audience that have been (privately) emailing you 
> while confused about why the hugepages being allocated from a global 
> tunable wouldn't be confined to their mempolicy.
> 

I hate to have to do this, but how about nr_hugepages which acts
system-wide as it did traditionally and nr_hugepages_mempolicy that obeys
policies? Something like the following untested patch. It would be fairly
trivial for me to implement a --obey-mempolicies switch for hugeadm which
works in conjunction with --pool--pages-min and less likely to cause confusion
than --hugepages-interleave in numactl.

Sorry the patch is untested. I can't hold of a NUMA machine at the moment
and fake NUMA support sucks far worse than I expected it to.

==== BEGIN PATCH ====

[PATCH] Optionally use a memory policy when tuning the size of the static hugepage pool

Patch "derive huge pages nodes allowed from task mempolicy" brought
huge page support more in line with the core VM in that tuning the size
of the static huge page pool would obey memory policies. Using this,
administrators could interleave allocation of huge pages from a subset
of nodes. This is consistent with how dynamic hugepage pool resizing
works and how hugepages get allocated to applications at run-time.

However, it was pointed out that scripts may exist that depend on being
able to drain all hugepages via /proc/sys/vm/nr_hugepages from processes
that are running within a memory policy. This patch adds
/proc/sys/vm/nr_hugepages_mempolicy which when written to will obey
memory policies. /proc/sys/vm/nr_hugepages continues then to be a
system-wide tunable regardless of memory policy.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
--- 
 include/linux/hugetlb.h |    1 +
 kernel/sysctl.c         |   11 +++++++++++
 mm/hugetlb.c            |   35 ++++++++++++++++++++++++++++++++---
 3 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index fcb1677..fc3a659 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -21,6 +21,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
 
 void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
 int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
+int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
 int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
 int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
 int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8bac3f5..0637655 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1171,6 +1171,17 @@ static struct ctl_table vm_table[] = {
 		.extra1		= (void *)&hugetlb_zero,
 		.extra2		= (void *)&hugetlb_infinity,
 	 },
+#ifdef CONFIG_NUMA
+	 {
+		.procname	= "nr_hugepages_mempolicy",
+		.data		= NULL,
+		.maxlen		= sizeof(unsigned long),
+		.mode		= 0644,
+		.proc_handler	= &hugetlb_mempolicy_sysctl_handler,
+		.extra1		= (void *)&hugetlb_zero,
+		.extra2		= (void *)&hugetlb_infinity,
+	 },
+#endif
 	 {
 		.ctl_name	= VM_HUGETLB_GROUP,
 		.procname	= "hugetlb_shm_group",
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 83decd6..68abef0 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
 	return ret;
 }
 
+#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
 #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
 static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
 								int nid)
@@ -1254,9 +1255,14 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
 	if (h->order >= MAX_ORDER)
 		return h->max_huge_pages;
 
-	if (nid == NUMA_NO_NODE) {
+	switch (nid) {
+	case NUMA_NO_NODE_OBEY_MEMPOLICY:
 		nodes_allowed = alloc_nodemask_of_mempolicy();
-	} else {
+		break;
+	case NUMA_NO_NODE:
+		nodes_allowed = NULL;
+		break;
+	default:
 		/*
 		 * incoming 'count' is for node 'nid' only, so
 		 * adjust count to global, but restrict alloc/free
@@ -1265,7 +1271,7 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
 		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
 		nodes_allowed = alloc_nodemask_of_node(nid);
 	}
-	if (!nodes_allowed) {
+	if (!nodes_allowed && nid != NUMA_NO_NODE) {
 		printk(KERN_WARNING "%s unable to allocate nodes allowed mask "
 			"for huge page allocation.  Falling back to default.\n",
 			current->comm);
@@ -1796,6 +1802,29 @@ int hugetlb_sysctl_handler(struct ctl_table *table, int write,
 	return 0;
 }
 
+#ifdef CONFIG_NUMA
+int hugetlb_mempolicy_sysctl_handler(struct ctl_table *table, int write,
+			   void __user *buffer,
+			   size_t *length, loff_t *ppos)
+{
+	struct hstate *h = &default_hstate;
+	unsigned long tmp;
+
+	if (!write)
+		tmp = h->max_huge_pages;
+
+	table->data = &tmp;
+	table->maxlen = sizeof(unsigned long);
+	proc_doulongvec_minmax(table, write, buffer, length, ppos);
+
+	if (write)
+		h->max_huge_pages = set_max_huge_pages(h, tmp,
+					NUMA_NO_NODE_OBEY_MEMPOLICY);
+
+	return 0;
+}
+#endif /* CONFIG_NUMA */
+
 int hugetlb_treat_movable_handler(struct ctl_table *table, int write,
 			void __user *buffer,
 			size_t *length, loff_t *ppos)

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with ESMTP id 7EEFE6B004D
	for <linux-mm@kvack.org>; Fri, 11 Sep 2009 18:27:32 -0400 (EDT)
Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78])
	by smtp-out.google.com with ESMTP id n8BMRbal030120
	for <linux-mm@kvack.org>; Fri, 11 Sep 2009 23:27:38 +0100
Received: from pzk35 (pzk35.prod.google.com [10.243.19.163])
	by zps78.corp.google.com with ESMTP id n8BMQW7V024121
	for <linux-mm@kvack.org>; Fri, 11 Sep 2009 15:27:35 -0700
Received: by pzk35 with SMTP id 35so1193729pzk.11
        for <linux-mm@kvack.org>; Fri, 11 Sep 2009 15:27:34 -0700 (PDT)
Date: Fri, 11 Sep 2009 15:27:30 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
In-Reply-To: <20090910122641.GA31153@csn.ul.ie>
Message-ID: <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com>
References: <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie>
 <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com>
 <20090910122641.GA31153@csn.ul.ie>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Thu, 10 Sep 2009, Mel Gorman wrote:

> > Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
> > and only using the new behavior when this is set would be inconsistent or 
> > inadvisible?
> 
> I already explained this. The interface in numactl would look weird. There
> would be an --interleave switch and a --hugepages-interleave that only
> applies to nr_hugepages. The smarts could be in hugeadm to apply the mask
> when --pool-pages-min is specified but that wouldn't help scripts that are
> still using echo.
> 

I don't think we need to address the scripts that are currently using echo 
since they're (hopefully) written to the kernel implementation, i.e. no 
mempolicy restriction on writing to nr_hugepages.

> I hate to have to do this, but how about nr_hugepages which acts
> system-wide as it did traditionally and nr_hugepages_mempolicy that obeys
> policies? Something like the following untested patch. It would be fairly
> trivial for me to implement a --obey-mempolicies switch for hugeadm which
> works in conjunction with --pool--pages-min and less likely to cause confusion
> than --hugepages-interleave in numactl.
> 

I like it.

> Sorry the patch is untested. I can't hold of a NUMA machine at the moment
> and fake NUMA support sucks far worse than I expected it to.
> 

Hmm, I rewrote most of fake NUMA a couple years ago.  What problems are 
you having with it?

> ==== BEGIN PATCH ====
> 
> [PATCH] Optionally use a memory policy when tuning the size of the static hugepage pool
> 
> Patch "derive huge pages nodes allowed from task mempolicy" brought
> huge page support more in line with the core VM in that tuning the size
> of the static huge page pool would obey memory policies. Using this,
> administrators could interleave allocation of huge pages from a subset
> of nodes. This is consistent with how dynamic hugepage pool resizing
> works and how hugepages get allocated to applications at run-time.
> 
> However, it was pointed out that scripts may exist that depend on being
> able to drain all hugepages via /proc/sys/vm/nr_hugepages from processes
> that are running within a memory policy. This patch adds
> /proc/sys/vm/nr_hugepages_mempolicy which when written to will obey
> memory policies. /proc/sys/vm/nr_hugepages continues then to be a
> system-wide tunable regardless of memory policy.
> 
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> --- 
>  include/linux/hugetlb.h |    1 +
>  kernel/sysctl.c         |   11 +++++++++++
>  mm/hugetlb.c            |   35 ++++++++++++++++++++++++++++++++---
>  3 files changed, 44 insertions(+), 3 deletions(-)
> 

It'll need an update to Documentation/vm/hugetlb.txt, but this can 
probably be done in one of Lee's patches that edits the same file when he 
reposts.

> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index fcb1677..fc3a659 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -21,6 +21,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
>  
>  void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
>  int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> +int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
>  int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
>  int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
>  int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 8bac3f5..0637655 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1171,6 +1171,17 @@ static struct ctl_table vm_table[] = {
>  		.extra1		= (void *)&hugetlb_zero,
>  		.extra2		= (void *)&hugetlb_infinity,
>  	 },
> +#ifdef CONFIG_NUMA
> +	 {
> +		.procname	= "nr_hugepages_mempolicy",
> +		.data		= NULL,
> +		.maxlen		= sizeof(unsigned long),
> +		.mode		= 0644,
> +		.proc_handler	= &hugetlb_mempolicy_sysctl_handler,
> +		.extra1		= (void *)&hugetlb_zero,
> +		.extra2		= (void *)&hugetlb_infinity,
> +	 },
> +#endif
>  	 {
>  		.ctl_name	= VM_HUGETLB_GROUP,
>  		.procname	= "hugetlb_shm_group",
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 83decd6..68abef0 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
>  	return ret;
>  }
>  
> +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
>  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
>  static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
>  								int nid)

I think it would be possible to avoid adding NUMA_NO_NODE_OBEY_MEMPOLICY 
if the nodemask was allocated in the sysctl handler instead and passing it 
into set_max_huge_pages() instead of a nid.  Lee, what do you think?


Other than that, I like this approach because it avoids the potential for 
userspace breakage while adding the new feature in way that avoids 
confusion.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Date: Mon, 14 Sep 2009 14:33:30 +0100
Message-ID: <20090914133329.GC11778@csn.ul.ie>
References: <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com>
Mime-Version: 1.0
Return-path: <owner-linux-mm@kvack.org>
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Fri, Sep 11, 2009 at 03:27:30PM -0700, David Rientjes wrote:
> On Thu, 10 Sep 2009, Mel Gorman wrote:
> 
> > > Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
> > > and only using the new behavior when this is set would be inconsistent or 
> > > inadvisible?
> > 
> > I already explained this. The interface in numactl would look weird. There
> > would be an --interleave switch and a --hugepages-interleave that only
> > applies to nr_hugepages. The smarts could be in hugeadm to apply the mask
> > when --pool-pages-min is specified but that wouldn't help scripts that are
> > still using echo.
> > 
> 
> I don't think we need to address the scripts that are currently using echo 
> since they're (hopefully) written to the kernel implementation, i.e. no 
> mempolicy restriction on writing to nr_hugepages.
> 

Ok.

> > I hate to have to do this, but how about nr_hugepages which acts
> > system-wide as it did traditionally and nr_hugepages_mempolicy that obeys
> > policies? Something like the following untested patch. It would be fairly
> > trivial for me to implement a --obey-mempolicies switch for hugeadm which
> > works in conjunction with --pool--pages-min and less likely to cause confusion
> > than --hugepages-interleave in numactl.
> > 
> 
> I like it.
> 

Ok, when I get this tested, I'll sent it as a follow-on patch to Lee's
for proper incorporation.

> > Sorry the patch is untested. I can't hold of a NUMA machine at the moment
> > and fake NUMA support sucks far worse than I expected it to.
> > 
> 
> Hmm, I rewrote most of fake NUMA a couple years ago.  What problems are 
> you having with it?
> 

On PPC64, the parameters behave differently. I couldn't convince it to
create more than one NUMA node. On x86-64, the NUMA nodes appeared to
exist and would be visible on /proc/buddyinfo for example but the sysfs
directories for the fake nodes were not created so nr_hugepages couldn't
be examined on a per-node basis for example.

> > ==== BEGIN PATCH ====
> > 
> > [PATCH] Optionally use a memory policy when tuning the size of the static hugepage pool
> > 
> > Patch "derive huge pages nodes allowed from task mempolicy" brought
> > huge page support more in line with the core VM in that tuning the size
> > of the static huge page pool would obey memory policies. Using this,
> > administrators could interleave allocation of huge pages from a subset
> > of nodes. This is consistent with how dynamic hugepage pool resizing
> > works and how hugepages get allocated to applications at run-time.
> > 
> > However, it was pointed out that scripts may exist that depend on being
> > able to drain all hugepages via /proc/sys/vm/nr_hugepages from processes
> > that are running within a memory policy. This patch adds
> > /proc/sys/vm/nr_hugepages_mempolicy which when written to will obey
> > memory policies. /proc/sys/vm/nr_hugepages continues then to be a
> > system-wide tunable regardless of memory policy.
> > 
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > --- 
> >  include/linux/hugetlb.h |    1 +
> >  kernel/sysctl.c         |   11 +++++++++++
> >  mm/hugetlb.c            |   35 ++++++++++++++++++++++++++++++++---
> >  3 files changed, 44 insertions(+), 3 deletions(-)
> > 
> 
> It'll need an update to Documentation/vm/hugetlb.txt, but this can 
> probably be done in one of Lee's patches that edits the same file when he 
> reposts.
> 

Agreed.

> > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > index fcb1677..fc3a659 100644
> > --- a/include/linux/hugetlb.h
> > +++ b/include/linux/hugetlb.h
> > @@ -21,6 +21,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
> >  
> >  void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
> >  int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > +int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> >  int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> >  int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> >  int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index 8bac3f5..0637655 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -1171,6 +1171,17 @@ static struct ctl_table vm_table[] = {
> >  		.extra1		= (void *)&hugetlb_zero,
> >  		.extra2		= (void *)&hugetlb_infinity,
> >  	 },
> > +#ifdef CONFIG_NUMA
> > +	 {
> > +		.procname	= "nr_hugepages_mempolicy",
> > +		.data		= NULL,
> > +		.maxlen		= sizeof(unsigned long),
> > +		.mode		= 0644,
> > +		.proc_handler	= &hugetlb_mempolicy_sysctl_handler,
> > +		.extra1		= (void *)&hugetlb_zero,
> > +		.extra2		= (void *)&hugetlb_infinity,
> > +	 },
> > +#endif
> >  	 {
> >  		.ctl_name	= VM_HUGETLB_GROUP,
> >  		.procname	= "hugetlb_shm_group",
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 83decd6..68abef0 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
> >  	return ret;
> >  }
> >  
> > +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
> >  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> >  static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> >  								int nid)
> 
> I think it would be possible to avoid adding NUMA_NO_NODE_OBEY_MEMPOLICY 
> if the nodemask was allocated in the sysctl handler instead and passing it 
> into set_max_huge_pages() instead of a nid.  Lee, what do you think?
> 
> Other than that, I like this approach because it avoids the potential for 
> userspace breakage while adding the new feature in way that avoids 
> confusion.
> 

Indeed. While the addition of another proc tunable sucks, it seems like
the only available compromise.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with ESMTP id 0D7286B004D
	for <linux-mm@kvack.org>; Mon, 14 Sep 2009 10:15:48 -0400 (EDT)
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
 mempolicy based management.
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
In-Reply-To: <20090914133329.GC11778@csn.ul.ie>
References: <20090908104409.GB28127@csn.ul.ie>
	 <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com>
	 <20090908200451.GA6481@csn.ul.ie>
	 <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com>
	 <20090908214109.GB6481@csn.ul.ie>
	 <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com>
	 <20090909081631.GB24614@csn.ul.ie>
	 <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com>
	 <20090910122641.GA31153@csn.ul.ie>
	 <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com>
	 <20090914133329.GC11778@csn.ul.ie>
Content-Type: text/plain
Date: Mon, 14 Sep 2009 10:15:48 -0400
Message-Id: <1252937748.17132.111.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: David Rientjes <rientjes@google.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Mon, 2009-09-14 at 14:33 +0100, Mel Gorman wrote:
> On Fri, Sep 11, 2009 at 03:27:30PM -0700, David Rientjes wrote:
> > On Thu, 10 Sep 2009, Mel Gorman wrote:
> > 
> > > > Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
> > > > and only using the new behavior when this is set would be inconsistent or 
> > > > inadvisible?
> > > 
> > > I already explained this. The interface in numactl would look weird. There
> > > would be an --interleave switch and a --hugepages-interleave that only
> > > applies to nr_hugepages. The smarts could be in hugeadm to apply the mask
> > > when --pool-pages-min is specified but that wouldn't help scripts that are
> > > still using echo.
> > > 
> > 
> > I don't think we need to address the scripts that are currently using echo 
> > since they're (hopefully) written to the kernel implementation, i.e. no 
> > mempolicy restriction on writing to nr_hugepages.
> > 
> 
> Ok.
> 
> > > I hate to have to do this, but how about nr_hugepages which acts
> > > system-wide as it did traditionally and nr_hugepages_mempolicy that obeys
> > > policies? Something like the following untested patch. It would be fairly
> > > trivial for me to implement a --obey-mempolicies switch for hugeadm which
> > > works in conjunction with --pool--pages-min and less likely to cause confusion
> > > than --hugepages-interleave in numactl.
> > > 
> > 
> > I like it.
> > 
> 
> Ok, when I get this tested, I'll sent it as a follow-on patch to Lee's
> for proper incorporation.
> 
> > > Sorry the patch is untested. I can't hold of a NUMA machine at the moment
> > > and fake NUMA support sucks far worse than I expected it to.
> > > 
> > 
> > Hmm, I rewrote most of fake NUMA a couple years ago.  What problems are 
> > you having with it?
> > 
> 
> On PPC64, the parameters behave differently. I couldn't convince it to
> create more than one NUMA node. On x86-64, the NUMA nodes appeared to
> exist and would be visible on /proc/buddyinfo for example but the sysfs
> directories for the fake nodes were not created so nr_hugepages couldn't
> be examined on a per-node basis for example.
> 
> > > ==== BEGIN PATCH ====
> > > 
> > > [PATCH] Optionally use a memory policy when tuning the size of the static hugepage pool
> > > 
> > > Patch "derive huge pages nodes allowed from task mempolicy" brought
> > > huge page support more in line with the core VM in that tuning the size
> > > of the static huge page pool would obey memory policies. Using this,
> > > administrators could interleave allocation of huge pages from a subset
> > > of nodes. This is consistent with how dynamic hugepage pool resizing
> > > works and how hugepages get allocated to applications at run-time.
> > > 
> > > However, it was pointed out that scripts may exist that depend on being
> > > able to drain all hugepages via /proc/sys/vm/nr_hugepages from processes
> > > that are running within a memory policy. This patch adds
> > > /proc/sys/vm/nr_hugepages_mempolicy which when written to will obey
> > > memory policies. /proc/sys/vm/nr_hugepages continues then to be a
> > > system-wide tunable regardless of memory policy.
> > > 
> > > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > > --- 
> > >  include/linux/hugetlb.h |    1 +
> > >  kernel/sysctl.c         |   11 +++++++++++
> > >  mm/hugetlb.c            |   35 ++++++++++++++++++++++++++++++++---
> > >  3 files changed, 44 insertions(+), 3 deletions(-)
> > > 
> > 
> > It'll need an update to Documentation/vm/hugetlb.txt, but this can 
> > probably be done in one of Lee's patches that edits the same file when he 
> > reposts.
> > 
> 
> Agreed.

So, I'm respinning V7 today.  Shall I add this in as a separate patch?

Also, see below:


> 
> > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > > index fcb1677..fc3a659 100644
> > > --- a/include/linux/hugetlb.h
> > > +++ b/include/linux/hugetlb.h
> > > @@ -21,6 +21,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
> > >  
> > >  void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
> > >  int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > +int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > >  int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > >  int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > >  int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
> > > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > > index 8bac3f5..0637655 100644
> > > --- a/kernel/sysctl.c
> > > +++ b/kernel/sysctl.c
> > > @@ -1171,6 +1171,17 @@ static struct ctl_table vm_table[] = {
> > >  		.extra1		= (void *)&hugetlb_zero,
> > >  		.extra2		= (void *)&hugetlb_infinity,
> > >  	 },
> > > +#ifdef CONFIG_NUMA
> > > +	 {
> > > +		.procname	= "nr_hugepages_mempolicy",
> > > +		.data		= NULL,
> > > +		.maxlen		= sizeof(unsigned long),
> > > +		.mode		= 0644,
> > > +		.proc_handler	= &hugetlb_mempolicy_sysctl_handler,
> > > +		.extra1		= (void *)&hugetlb_zero,
> > > +		.extra2		= (void *)&hugetlb_infinity,
> > > +	 },
> > > +#endif
> > >  	 {
> > >  		.ctl_name	= VM_HUGETLB_GROUP,
> > >  		.procname	= "hugetlb_shm_group",
> > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > index 83decd6..68abef0 100644
> > > --- a/mm/hugetlb.c
> > > +++ b/mm/hugetlb.c
> > > @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
> > >  	return ret;
> > >  }
> > >  
> > > +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)

How about defining NUMA_NO_NODE_OBEY_MEMPOLICY as (NUMA_NO_NODE - 1)
just to ensure that it's different.  Not sure it's worth an enum at this
point.  NUMA_NO_NODE_OBEY_MEMPOLICY is private to hugetlb at this time.

> > >  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> > >  static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> > >  								int nid)
> > 
> > I think it would be possible to avoid adding NUMA_NO_NODE_OBEY_MEMPOLICY 
> > if the nodemask was allocated in the sysctl handler instead and passing it 
> > into set_max_huge_pages() instead of a nid.  Lee, what do you think?
> > 
> > Other than that, I like this approach because it avoids the potential for 
> > userspace breakage while adding the new feature in way that avoids 
> > confusion.
> > 
> 
> Indeed. While the addition of another proc tunable sucks, it seems like
> the only available compromise.

And, I supposed we need to replicate this under the global sysfs
hstates?

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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3])
	by kanga.kvack.org (Postfix) with ESMTP id 830266B004F
	for <linux-mm@kvack.org>; Mon, 14 Sep 2009 11:41:11 -0400 (EDT)
Date: Mon, 14 Sep 2009 16:41:12 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Message-ID: <20090914154112.GD11778@csn.ul.ie>
References: <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com> <20090914133329.GC11778@csn.ul.ie> <1252937748.17132.111.camel@useless.americas.hpqcorp.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <1252937748.17132.111.camel@useless.americas.hpqcorp.net>
Sender: owner-linux-mm@kvack.org
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: David Rientjes <rientjes@google.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Mon, Sep 14, 2009 at 10:15:48AM -0400, Lee Schermerhorn wrote:
> On Mon, 2009-09-14 at 14:33 +0100, Mel Gorman wrote:
> > On Fri, Sep 11, 2009 at 03:27:30PM -0700, David Rientjes wrote:
> > > On Thu, 10 Sep 2009, Mel Gorman wrote:
> > > 
> > > > > Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
> > > > > and only using the new behavior when this is set would be inconsistent or 
> > > > > inadvisible?
> > > > 
> > > > I already explained this. The interface in numactl would look weird. There
> > > > would be an --interleave switch and a --hugepages-interleave that only
> > > > applies to nr_hugepages. The smarts could be in hugeadm to apply the mask
> > > > when --pool-pages-min is specified but that wouldn't help scripts that are
> > > > still using echo.
> > > > 
> > > 
> > > I don't think we need to address the scripts that are currently using echo 
> > > since they're (hopefully) written to the kernel implementation, i.e. no 
> > > mempolicy restriction on writing to nr_hugepages.
> > > 
> > 
> > Ok.
> > 
> > > > I hate to have to do this, but how about nr_hugepages which acts
> > > > system-wide as it did traditionally and nr_hugepages_mempolicy that obeys
> > > > policies? Something like the following untested patch. It would be fairly
> > > > trivial for me to implement a --obey-mempolicies switch for hugeadm which
> > > > works in conjunction with --pool--pages-min and less likely to cause confusion
> > > > than --hugepages-interleave in numactl.
> > > > 
> > > 
> > > I like it.
> > > 
> > 
> > Ok, when I get this tested, I'll sent it as a follow-on patch to Lee's
> > for proper incorporation.
> > 
> > > > Sorry the patch is untested. I can't hold of a NUMA machine at the moment
> > > > and fake NUMA support sucks far worse than I expected it to.
> > > > 
> > > 
> > > Hmm, I rewrote most of fake NUMA a couple years ago.  What problems are 
> > > you having with it?
> > > 
> > 
> > On PPC64, the parameters behave differently. I couldn't convince it to
> > create more than one NUMA node. On x86-64, the NUMA nodes appeared to
> > exist and would be visible on /proc/buddyinfo for example but the sysfs
> > directories for the fake nodes were not created so nr_hugepages couldn't
> > be examined on a per-node basis for example.
> > 
> > > > ==== BEGIN PATCH ====
> > > > 
> > > > [PATCH] Optionally use a memory policy when tuning the size of the static hugepage pool
> > > > 
> > > > Patch "derive huge pages nodes allowed from task mempolicy" brought
> > > > huge page support more in line with the core VM in that tuning the size
> > > > of the static huge page pool would obey memory policies. Using this,
> > > > administrators could interleave allocation of huge pages from a subset
> > > > of nodes. This is consistent with how dynamic hugepage pool resizing
> > > > works and how hugepages get allocated to applications at run-time.
> > > > 
> > > > However, it was pointed out that scripts may exist that depend on being
> > > > able to drain all hugepages via /proc/sys/vm/nr_hugepages from processes
> > > > that are running within a memory policy. This patch adds
> > > > /proc/sys/vm/nr_hugepages_mempolicy which when written to will obey
> > > > memory policies. /proc/sys/vm/nr_hugepages continues then to be a
> > > > system-wide tunable regardless of memory policy.
> > > > 
> > > > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > > > --- 
> > > >  include/linux/hugetlb.h |    1 +
> > > >  kernel/sysctl.c         |   11 +++++++++++
> > > >  mm/hugetlb.c            |   35 ++++++++++++++++++++++++++++++++---
> > > >  3 files changed, 44 insertions(+), 3 deletions(-)
> > > > 
> > > 
> > > It'll need an update to Documentation/vm/hugetlb.txt, but this can 
> > > probably be done in one of Lee's patches that edits the same file when he 
> > > reposts.
> > > 
> > 
> > Agreed.
> 
> So, I'm respinning V7 today.  Shall I add this in as a separate patch?
> 

If you can, it'd be great but I can also spin a patch on top of yours
and update the documentation accordingly if you prefer.

> Also, see below:
> 
> 
> > 
> > > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > > > index fcb1677..fc3a659 100644
> > > > --- a/include/linux/hugetlb.h
> > > > +++ b/include/linux/hugetlb.h
> > > > @@ -21,6 +21,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
> > > >  
> > > >  void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
> > > >  int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > > +int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > >  int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > >  int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > >  int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
> > > > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > > > index 8bac3f5..0637655 100644
> > > > --- a/kernel/sysctl.c
> > > > +++ b/kernel/sysctl.c
> > > > @@ -1171,6 +1171,17 @@ static struct ctl_table vm_table[] = {
> > > >  		.extra1		= (void *)&hugetlb_zero,
> > > >  		.extra2		= (void *)&hugetlb_infinity,
> > > >  	 },
> > > > +#ifdef CONFIG_NUMA
> > > > +	 {
> > > > +		.procname	= "nr_hugepages_mempolicy",
> > > > +		.data		= NULL,
> > > > +		.maxlen		= sizeof(unsigned long),
> > > > +		.mode		= 0644,
> > > > +		.proc_handler	= &hugetlb_mempolicy_sysctl_handler,
> > > > +		.extra1		= (void *)&hugetlb_zero,
> > > > +		.extra2		= (void *)&hugetlb_infinity,
> > > > +	 },
> > > > +#endif
> > > >  	 {
> > > >  		.ctl_name	= VM_HUGETLB_GROUP,
> > > >  		.procname	= "hugetlb_shm_group",
> > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > index 83decd6..68abef0 100644
> > > > --- a/mm/hugetlb.c
> > > > +++ b/mm/hugetlb.c
> > > > @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
> > > >  	return ret;
> > > >  }
> > > >  
> > > > +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
> 
> How about defining NUMA_NO_NODE_OBEY_MEMPOLICY as (NUMA_NO_NODE - 1)
> just to ensure that it's different.  Not sure it's worth an enum at this
> point.  NUMA_NO_NODE_OBEY_MEMPOLICY is private to hugetlb at this time.
> 

That seems reasonable.

> > > >  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> > > >  static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> > > >  								int nid)
> > > 
> > > I think it would be possible to avoid adding NUMA_NO_NODE_OBEY_MEMPOLICY 
> > > if the nodemask was allocated in the sysctl handler instead and passing it 
> > > into set_max_huge_pages() instead of a nid.  Lee, what do you think?
> > > 
> > > Other than that, I like this approach because it avoids the potential for 
> > > userspace breakage while adding the new feature in way that avoids 
> > > confusion.
> > > 
> > 
> > Indeed. While the addition of another proc tunable sucks, it seems like
> > the only available compromise.
> 
> And, I supposed we need to replicate this under the global sysfs
> hstates?
> 

You're right, they would also be needed under /sys/kernel/mm/hugepages/*

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3])
	by kanga.kvack.org (Postfix) with ESMTP id 2405E6B004D
	for <linux-mm@kvack.org>; Mon, 14 Sep 2009 15:14:10 -0400 (EDT)
Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142])
	by smtp-out.google.com with ESMTP id n8EJEBJ5011264
	for <linux-mm@kvack.org>; Mon, 14 Sep 2009 12:14:12 -0700
Received: from pxi27 (pxi27.prod.google.com [10.243.27.27])
	by spaceape8.eur.corp.google.com with ESMTP id n8EJE897011218
	for <linux-mm@kvack.org>; Mon, 14 Sep 2009 12:14:09 -0700
Received: by pxi27 with SMTP id 27so2555896pxi.15
        for <linux-mm@kvack.org>; Mon, 14 Sep 2009 12:14:08 -0700 (PDT)
Date: Mon, 14 Sep 2009 12:14:05 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
In-Reply-To: <20090914133329.GC11778@csn.ul.ie>
Message-ID: <alpine.DEB.1.00.0909141213150.14000@chino.kir.corp.google.com>
References: <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie>
 <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com>
 <20090914133329.GC11778@csn.ul.ie>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Mon, 14 Sep 2009, Mel Gorman wrote:

> > Hmm, I rewrote most of fake NUMA a couple years ago.  What problems are 
> > you having with it?
> > 
> 
> On PPC64, the parameters behave differently. I couldn't convince it to
> create more than one NUMA node. On x86-64, the NUMA nodes appeared to
> exist and would be visible on /proc/buddyinfo for example but the sysfs
> directories for the fake nodes were not created so nr_hugepages couldn't
> be examined on a per-node basis for example.
> 

I don't know anything about the ppc64 fake NUMA, but the sysfs node 
directories should certainly be created on x86_64.  I'll look into it 
because that's certainly a bug.  Thanks.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with ESMTP id D0BC66B005D
	for <linux-mm@kvack.org>; Mon, 14 Sep 2009 15:15:45 -0400 (EDT)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88])
	by smtp-out.google.com with ESMTP id n8EJFlH9012152
	for <linux-mm@kvack.org>; Mon, 14 Sep 2009 20:15:47 +0100
Received: from pzk10 (pzk10.prod.google.com [10.243.19.138])
	by wpaz24.hot.corp.google.com with ESMTP id n8EJDeqn031369
	for <linux-mm@kvack.org>; Mon, 14 Sep 2009 12:15:45 -0700
Received: by pzk10 with SMTP id 10so20068pzk.17
        for <linux-mm@kvack.org>; Mon, 14 Sep 2009 12:15:44 -0700 (PDT)
Date: Mon, 14 Sep 2009 12:15:43 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
In-Reply-To: <20090914154112.GD11778@csn.ul.ie>
Message-ID: <alpine.DEB.1.00.0909141214170.14000@chino.kir.corp.google.com>
References: <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie>
 <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com> <20090914133329.GC11778@csn.ul.ie> <1252937748.17132.111.camel@useless.americas.hpqcorp.net>
 <20090914154112.GD11778@csn.ul.ie>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Mon, 14 Sep 2009, Mel Gorman wrote:

> > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > > index 83decd6..68abef0 100644
> > > > > --- a/mm/hugetlb.c
> > > > > +++ b/mm/hugetlb.c
> > > > > @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
> > > > >  	return ret;
> > > > >  }
> > > > >  
> > > > > +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
> > 
> > How about defining NUMA_NO_NODE_OBEY_MEMPOLICY as (NUMA_NO_NODE - 1)
> > just to ensure that it's different.  Not sure it's worth an enum at this
> > point.  NUMA_NO_NODE_OBEY_MEMPOLICY is private to hugetlb at this time.
> > 
> 
> That seems reasonable.
> 

If the nodemask allocation is moved to the sysctl handler and nodemask_t 
is passed into set_max_huge_pages() instead of nid, you don't need 
NUMA_NO_NODE_OBEY_MEMPOLICY at all, though.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Mon, 14 Sep 2009 14:28:27 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909141421540.22563@chino.kir.corp.google.com>
References: <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie>
 <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com>
 <20090914133329.GC11778@csn.ul.ie> <alpine.DEB.1.00.0909141213150.14000@chino.kir.corp.google.com>
Mime-Version: 1.0
Return-path: <owner-linux-mm@kvack.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252963714; bh=AQAoIbHGqcXYnHd3zzGBfyYOCBw=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=S8B2j0YSbWJ/QqKY9pON8ha71acRxM3
	MOce8tD4HuKrCS/xy8jFhVsybzUP7d7EI91+6QeX6X80Zw2LnlyyIRg==
In-Reply-To: <alpine.DEB.1.00.0909141213150.14000@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Mon, 14 Sep 2009, David Rientjes wrote:

> > On PPC64, the parameters behave differently. I couldn't convince it to
> > create more than one NUMA node. On x86-64, the NUMA nodes appeared to
> > exist and would be visible on /proc/buddyinfo for example but the sysfs
> > directories for the fake nodes were not created so nr_hugepages couldn't
> > be examined on a per-node basis for example.
> > 
> 
> I don't know anything about the ppc64 fake NUMA, but the sysfs node 
> directories should certainly be created on x86_64.  I'll look into it 
> because that's certainly a bug.  Thanks.
> 

This works on my machine just fine.

For example, with numa=fake=8:

	$ ls /sys/devices/system/node
	has_cpu  has_normal_memory  node0  node1  node2  node3  node4  
node5  node6  node7  online  possible

	$ ls /sys/devices/system/node/node3
	cpu4  cpu5  cpu6  cpu7  cpulist  cpumap  distance  meminfo  
numastat  scan_unevictable_pages

I don't see how this could differ if bootmem is setting up the nodes 
correctly, which dmesg | grep "^Bootmem setup node" would reveal.

The defconfig disables CONFIG_NUMA_EMU now, though, so perhaps it got 
turned off by accident in your kernel?

Let me know if there's any abnormalities with your particular setup.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51])
	by kanga.kvack.org (Postfix) with ESMTP id 0916E6B0055
	for <linux-mm@kvack.org>; Tue, 15 Sep 2009 07:48:39 -0400 (EDT)
Date: Tue, 15 Sep 2009 12:48:45 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Message-ID: <20090915114844.GA31840@csn.ul.ie>
References: <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com> <20090914133329.GC11778@csn.ul.ie> <1252937748.17132.111.camel@useless.americas.hpqcorp.net> <20090914154112.GD11778@csn.ul.ie> <alpine.DEB.1.00.0909141214170.14000@chino.kir.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909141214170.14000@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>
List-ID: <linux-mm.kvack.org>

On Mon, Sep 14, 2009 at 12:15:43PM -0700, David Rientjes wrote:
> On Mon, 14 Sep 2009, Mel Gorman wrote:
> 
> > > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > > > index 83decd6..68abef0 100644
> > > > > > --- a/mm/hugetlb.c
> > > > > > +++ b/mm/hugetlb.c
> > > > > > @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
> > > > > >  	return ret;
> > > > > >  }
> > > > > >  
> > > > > > +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
> > > 
> > > How about defining NUMA_NO_NODE_OBEY_MEMPOLICY as (NUMA_NO_NODE - 1)
> > > just to ensure that it's different.  Not sure it's worth an enum at this
> > > point.  NUMA_NO_NODE_OBEY_MEMPOLICY is private to hugetlb at this time.
> > > 
> > 
> > That seems reasonable.
> > 
> 
> If the nodemask allocation is moved to the sysctl handler and nodemask_t 
> is passed into set_max_huge_pages() instead of nid, you don't need 
> NUMA_NO_NODE_OBEY_MEMPOLICY at all, though.
> 

Very likely. When V7 comes out, I'll spin a patch for that and see what
it looks like if Lee doesn't beat me to it.


-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Date: Wed, 16 Sep 2009 11:21:24 +0100
Message-ID: <20090916102124.GC1993@csn.ul.ie>
References: <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com> <20090914133329.GC11778@csn.ul.ie> <alpine.DEB.1.00.0909141213150.14000@chino.kir.corp.google.com> <alpine.DEB.1.00.0909141421540.22563@chino.kir.corp.google.com>
Mime-Version: 1.0
Return-path: <owner-linux-mm@kvack.org>
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909141421540.22563@chino.kir.corp.google.com>
Sender: owner-linux-mm@kvack.org
List-Id: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Mon, Sep 14, 2009 at 02:28:27PM -0700, David Rientjes wrote:
> On Mon, 14 Sep 2009, David Rientjes wrote:
> 
> > > On PPC64, the parameters behave differently. I couldn't convince it to
> > > create more than one NUMA node. On x86-64, the NUMA nodes appeared to
> > > exist and would be visible on /proc/buddyinfo for example but the sysfs
> > > directories for the fake nodes were not created so nr_hugepages couldn't
> > > be examined on a per-node basis for example.
> > > 
> > 
> > I don't know anything about the ppc64 fake NUMA, but the sysfs node 
> > directories should certainly be created on x86_64.  I'll look into it 
> > because that's certainly a bug.  Thanks.
> > 
> 
> This works on my machine just fine.
> 
> For example, with numa=fake=8:
> 
> 	$ ls /sys/devices/system/node
> 	has_cpu  has_normal_memory  node0  node1  node2  node3  node4  
> node5  node6  node7  online  possible
> 
> 	$ ls /sys/devices/system/node/node3
> 	cpu4  cpu5  cpu6  cpu7  cpulist  cpumap  distance  meminfo  
> numastat  scan_unevictable_pages
> 
> I don't see how this could differ if bootmem is setting up the nodes 
> correctly, which dmesg | grep "^Bootmem setup node" would reveal.
> 
> The defconfig disables CONFIG_NUMA_EMU now, though, so perhaps it got 
> turned off by accident in your kernel?
> 

I don't think so because my recollection is that the nodes existed
according to meminfo and buddyinfo but not the sysfs files.
Unfortunately I can't remember the reproduction scenario. I thought it
was on mmotm-2009-08-27-16-51 on a particularly machine but when I went
to reproduce, it didn't even boot so somewhere along the line I busted
things.

> Let me know if there's any abnormalities with your particular setup.
> 

Will try reproducing on more recent mmotm and see if anything odd falls
out.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: [PATCH 0/6] hugetlb: V5 constrain allocation/free based on task mempolicy
Date: Fri, 28 Aug 2009 12:03:14 -0400
Message-ID: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Return-path: <linux-numa-owner@vger.kernel.org>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

PATCH 0/6 hugetlb: numa control of persistent huge pages alloc/free

Against:  2.6.31-rc7-mmotm-090827-0057

This is V5 of a series of patches to provide control over the location
of the allocation and freeing of persistent huge pages on a NUMA
platform.

This series uses the task NUMA mempolicy of the task modifying
"nr_hugepages" to constrain the affected nodes.  This method is
based on Mel Gorman's suggestion to use task mempolicy.  One of
the benefits of this method is that it does not *require*
modification to hugeadm(8) to use this feature.  One of the possible
downsides is that task mempolicy is limited by cpuset constraints.

V4 added a subset of the hugepages sysfs attributes to each per
node system device directory under:

	/sys/devices/node/node[0-9]*/hugepages.

The per node attibutes allow direct assignment of a huge page
count on a specific node, regardless of the task's mempolicy or
cpuset constraints.

V5 addresses review comments -- changes described in patch
descriptions.  Should be almost ready for -mm?

Note, I haven't implemented a boot time parameter to constrain the
boot time allocation of huge pages.  This can be added if anyone feels
strongly that it is required.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: [PATCH 1/6] hugetlb:  rework hstate_next_node_* functions
Date: Fri, 28 Aug 2009 12:03:21 -0400
Message-ID: <20090828160321.11080.93497.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

[PATCH 1/6] hugetlb:  rework hstate_next_node* functions

Against:  2.6.31-rc7-mmotm-090827-0057

V2:
+ cleaned up comments, removed some deemed unnecessary,
  add some suggested by review
+ removed check for !current in huge_mpol_nodes_allowed().
+ added 'current->comm' to warning message in huge_mpol_nodes_allowed().
+ added VM_BUG_ON() assertion in hugetlb.c next_node_allowed() to
  catch out of range node id.
+ add examples to patch description

V3:
+ factored this "cleanup" patch out of V2 patch 2/3
+ moved ahead of patch to add nodes_allowed mask to alloc funcs
  as this patch is somewhat independent from using task mempolicy
  to control huge page allocation and freeing.

Modify the hstate_next_node* functions to allow them to be called to
obtain the "start_nid".  Then, whereas prior to this patch we
unconditionally called hstate_next_node_to_{alloc|free}(), whether
or not we successfully allocated/freed a huge page on the node,
now we only call these functions on failure to alloc/free to advance
to next allowed node.

Factor out the next_node_allowed() function to handle wrap at end
of node_online_map.  In this version, the allowed nodes include all 
of the online nodes.

Acked-by: David Rientjes <rientjes@google.com>
Reviewed-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 mm/hugetlb.c |   70 +++++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 45 insertions(+), 25 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-27 13:12:12.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:21.000000000 -0400
@@ -622,6 +622,20 @@ static struct page *alloc_fresh_huge_pag
 }
 
 /*
+ * common helper function for hstate_next_node_to_{alloc|free}.
+ * return next node in node_online_map, wrapping at end.
+ */
+static int next_node_allowed(int nid)
+{
+	nid = next_node(nid, node_online_map);
+	if (nid == MAX_NUMNODES)
+		nid = first_node(node_online_map);
+	VM_BUG_ON(nid >= MAX_NUMNODES);
+
+	return nid;
+}
+
+/*
  * Use a helper variable to find the next node and then
  * copy it back to next_nid_to_alloc afterwards:
  * otherwise there's a window in which a racer might
@@ -634,12 +648,12 @@ static struct page *alloc_fresh_huge_pag
  */
 static int hstate_next_node_to_alloc(struct hstate *h)
 {
-	int next_nid;
-	next_nid = next_node(h->next_nid_to_alloc, node_online_map);
-	if (next_nid == MAX_NUMNODES)
-		next_nid = first_node(node_online_map);
+	int nid, next_nid;
+
+	nid = h->next_nid_to_alloc;
+	next_nid = next_node_allowed(nid);
 	h->next_nid_to_alloc = next_nid;
-	return next_nid;
+	return nid;
 }
 
 static int alloc_fresh_huge_page(struct hstate *h)
@@ -649,15 +663,17 @@ static int alloc_fresh_huge_page(struct
 	int next_nid;
 	int ret = 0;
 
-	start_nid = h->next_nid_to_alloc;
+	start_nid = hstate_next_node_to_alloc(h);
 	next_nid = start_nid;
 
 	do {
 		page = alloc_fresh_huge_page_node(h, next_nid);
-		if (page)
+		if (page) {
 			ret = 1;
+			break;
+		}
 		next_nid = hstate_next_node_to_alloc(h);
-	} while (!page && next_nid != start_nid);
+	} while (next_nid != start_nid);
 
 	if (ret)
 		count_vm_event(HTLB_BUDDY_PGALLOC);
@@ -668,17 +684,19 @@ static int alloc_fresh_huge_page(struct
 }
 
 /*
- * helper for free_pool_huge_page() - find next node
- * from which to free a huge page
+ * helper for free_pool_huge_page() - return the next node
+ * from which to free a huge page.  Advance the next node id
+ * whether or not we find a free huge page to free so that the
+ * next attempt to free addresses the next node.
  */
 static int hstate_next_node_to_free(struct hstate *h)
 {
-	int next_nid;
-	next_nid = next_node(h->next_nid_to_free, node_online_map);
-	if (next_nid == MAX_NUMNODES)
-		next_nid = first_node(node_online_map);
+	int nid, next_nid;
+
+	nid = h->next_nid_to_free;
+	next_nid = next_node_allowed(nid);
 	h->next_nid_to_free = next_nid;
-	return next_nid;
+	return nid;
 }
 
 /*
@@ -693,7 +711,7 @@ static int free_pool_huge_page(struct hs
 	int next_nid;
 	int ret = 0;
 
-	start_nid = h->next_nid_to_free;
+	start_nid = hstate_next_node_to_free(h);
 	next_nid = start_nid;
 
 	do {
@@ -715,9 +733,10 @@ static int free_pool_huge_page(struct hs
 			}
 			update_and_free_page(h, page);
 			ret = 1;
+			break;
 		}
 		next_nid = hstate_next_node_to_free(h);
-	} while (!ret && next_nid != start_nid);
+	} while (next_nid != start_nid);
 
 	return ret;
 }
@@ -1028,10 +1047,9 @@ int __weak alloc_bootmem_huge_page(struc
 		void *addr;
 
 		addr = __alloc_bootmem_node_nopanic(
-				NODE_DATA(h->next_nid_to_alloc),
+				NODE_DATA(hstate_next_node_to_alloc(h)),
 				huge_page_size(h), huge_page_size(h), 0);
 
-		hstate_next_node_to_alloc(h);
 		if (addr) {
 			/*
 			 * Use the beginning of the huge page to store the
@@ -1167,29 +1185,31 @@ static int adjust_pool_surplus(struct hs
 	VM_BUG_ON(delta != -1 && delta != 1);
 
 	if (delta < 0)
-		start_nid = h->next_nid_to_alloc;
+		start_nid = hstate_next_node_to_alloc(h);
 	else
-		start_nid = h->next_nid_to_free;
+		start_nid = hstate_next_node_to_free(h);
 	next_nid = start_nid;
 
 	do {
 		int nid = next_nid;
 		if (delta < 0)  {
-			next_nid = hstate_next_node_to_alloc(h);
 			/*
 			 * To shrink on this node, there must be a surplus page
 			 */
-			if (!h->surplus_huge_pages_node[nid])
+			if (!h->surplus_huge_pages_node[nid]) {
+				next_nid = hstate_next_node_to_alloc(h);
 				continue;
+			}
 		}
 		if (delta > 0) {
-			next_nid = hstate_next_node_to_free(h);
 			/*
 			 * Surplus cannot exceed the total number of pages
 			 */
 			if (h->surplus_huge_pages_node[nid] >=
-						h->nr_huge_pages_node[nid])
+						h->nr_huge_pages_node[nid]) {
+				next_nid = hstate_next_node_to_free(h);
 				continue;
+			}
 		}
 
 		h->surplus_huge_pages += delta;

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: [PATCH 2/6] hugetlb:  add nodemask arg to huge page alloc, free and surplus adjust fcns
Date: Fri, 28 Aug 2009 12:03:26 -0400
Message-ID: <20090828160326.11080.56814.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

[PATCH 2/6] hugetlb:  add nodemask arg to huge page alloc, free and surplus adjust fcns

Against:  2.6.31-rc7-mmotm-090827-0057

V3:
+ moved this patch to after the "rework" of hstate_next_node_to_...
  functions as this patch is more specific to using task mempolicy
  to control huge page allocation and freeing.

V5:
+ removed now unneeded 'nextnid' from hstate_next_node_to_{alloc|free}
  and updated the stale comments.

In preparation for constraining huge page allocation and freeing by the
controlling task's numa mempolicy, add a "nodes_allowed" nodemask pointer
to the allocate, free and surplus adjustment functions.  For now, pass
NULL to indicate default behavior--i.e., use node_online_map.  A
subsqeuent patch will derive a non-default mask from the controlling 
task's numa mempolicy.

Note that this method of updating the global hstate nr_hugepages under
the constraint of a nodemask simplifies keeping the global state 
consistent--especially the number of persistent and surplus pages
relative to reservations and overcommit limits.  There are undoubtedly
other ways to do this, but this works for both interfaces:  mempolicy
and per node attributes.

Reviewed-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 mm/hugetlb.c |  121 +++++++++++++++++++++++++++++++++++------------------------
 1 file changed, 72 insertions(+), 49 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:21.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:26.000000000 -0400
@@ -622,48 +622,57 @@ static struct page *alloc_fresh_huge_pag
 }
 
 /*
- * common helper function for hstate_next_node_to_{alloc|free}.
- * return next node in node_online_map, wrapping at end.
+ * common helper functions for hstate_next_node_to_{alloc|free}.
+ * We may have allocated or freed a huge page based on a different
+ * nodes_allowed previously, so h->next_node_to_{alloc|free} might
+ * be outside of *nodes_allowed.  Ensure that we use an allowed
+ * node for alloc or free.
  */
-static int next_node_allowed(int nid)
+static int next_node_allowed(int nid, nodemask_t *nodes_allowed)
 {
-	nid = next_node(nid, node_online_map);
+	nid = next_node(nid, *nodes_allowed);
 	if (nid == MAX_NUMNODES)
-		nid = first_node(node_online_map);
+		nid = first_node(*nodes_allowed);
 	VM_BUG_ON(nid >= MAX_NUMNODES);
 
 	return nid;
 }
 
+static int this_node_allowed(int nid, nodemask_t *nodes_allowed)
+{
+	if (!node_isset(nid, *nodes_allowed))
+		nid = next_node_allowed(nid, nodes_allowed);
+	return nid;
+}
+
 /*
- * Use a helper variable to find the next node and then
- * copy it back to next_nid_to_alloc afterwards:
- * otherwise there's a window in which a racer might
- * pass invalid nid MAX_NUMNODES to alloc_pages_exact_node.
- * But we don't need to use a spin_lock here: it really
- * doesn't matter if occasionally a racer chooses the
- * same nid as we do.  Move nid forward in the mask even
- * if we just successfully allocated a hugepage so that
- * the next caller gets hugepages on the next node.
+ * returns the previously saved node ["this node"] from which to
+ * allocate a persistent huge page for the pool and advance the
+ * next node from which to allocate, handling wrap at end of node
+ * mask.  'nodes_allowed' defaults to node_online_map.
  */
-static int hstate_next_node_to_alloc(struct hstate *h)
+static int hstate_next_node_to_alloc(struct hstate *h,
+					nodemask_t *nodes_allowed)
 {
-	int nid, next_nid;
+	int nid;
+
+	if (!nodes_allowed)
+		nodes_allowed = &node_online_map;
+
+	nid = this_node_allowed(h->next_nid_to_alloc, nodes_allowed);
+	h->next_nid_to_alloc = next_node_allowed(nid, nodes_allowed);
 
-	nid = h->next_nid_to_alloc;
-	next_nid = next_node_allowed(nid);
-	h->next_nid_to_alloc = next_nid;
 	return nid;
 }
 
-static int alloc_fresh_huge_page(struct hstate *h)
+static int alloc_fresh_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
 {
 	struct page *page;
 	int start_nid;
 	int next_nid;
 	int ret = 0;
 
-	start_nid = hstate_next_node_to_alloc(h);
+	start_nid = hstate_next_node_to_alloc(h, nodes_allowed);
 	next_nid = start_nid;
 
 	do {
@@ -672,7 +681,7 @@ static int alloc_fresh_huge_page(struct
 			ret = 1;
 			break;
 		}
-		next_nid = hstate_next_node_to_alloc(h);
+		next_nid = hstate_next_node_to_alloc(h, nodes_allowed);
 	} while (next_nid != start_nid);
 
 	if (ret)
@@ -684,18 +693,21 @@ static int alloc_fresh_huge_page(struct
 }
 
 /*
- * helper for free_pool_huge_page() - return the next node
- * from which to free a huge page.  Advance the next node id
- * whether or not we find a free huge page to free so that the
- * next attempt to free addresses the next node.
+ * helper for free_pool_huge_page() - return the previously saved
+ * node ["this node"] from which to free a huge page.  Advance the
+ * next node id whether or not we find a free huge page to free so
+ * that the next attempt to free addresses the next node.
  */
-static int hstate_next_node_to_free(struct hstate *h)
+static int hstate_next_node_to_free(struct hstate *h, nodemask_t *nodes_allowed)
 {
-	int nid, next_nid;
+	int nid;
+
+	if (!nodes_allowed)
+		nodes_allowed = &node_online_map;
+
+	nid = this_node_allowed(h->next_nid_to_free, nodes_allowed);
+	h->next_nid_to_free = next_node_allowed(nid, nodes_allowed);
 
-	nid = h->next_nid_to_free;
-	next_nid = next_node_allowed(nid);
-	h->next_nid_to_free = next_nid;
 	return nid;
 }
 
@@ -705,13 +717,14 @@ static int hstate_next_node_to_free(stru
  * balanced over allowed nodes.
  * Called with hugetlb_lock locked.
  */
-static int free_pool_huge_page(struct hstate *h, bool acct_surplus)
+static int free_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed,
+							 bool acct_surplus)
 {
 	int start_nid;
 	int next_nid;
 	int ret = 0;
 
-	start_nid = hstate_next_node_to_free(h);
+	start_nid = hstate_next_node_to_free(h, nodes_allowed);
 	next_nid = start_nid;
 
 	do {
@@ -735,7 +748,7 @@ static int free_pool_huge_page(struct hs
 			ret = 1;
 			break;
 		}
-		next_nid = hstate_next_node_to_free(h);
+		next_nid = hstate_next_node_to_free(h, nodes_allowed);
 	} while (next_nid != start_nid);
 
 	return ret;
@@ -937,7 +950,7 @@ static void return_unused_surplus_pages(
 	 * on-line nodes for us and will handle the hstate accounting.
 	 */
 	while (nr_pages--) {
-		if (!free_pool_huge_page(h, 1))
+		if (!free_pool_huge_page(h, NULL, 1))
 			break;
 	}
 }
@@ -1047,7 +1060,7 @@ int __weak alloc_bootmem_huge_page(struc
 		void *addr;
 
 		addr = __alloc_bootmem_node_nopanic(
-				NODE_DATA(hstate_next_node_to_alloc(h)),
+				NODE_DATA(hstate_next_node_to_alloc(h, NULL)),
 				huge_page_size(h), huge_page_size(h), 0);
 
 		if (addr) {
@@ -1102,7 +1115,7 @@ static void __init hugetlb_hstate_alloc_
 		if (h->order >= MAX_ORDER) {
 			if (!alloc_bootmem_huge_page(h))
 				break;
-		} else if (!alloc_fresh_huge_page(h))
+		} else if (!alloc_fresh_huge_page(h, NULL))
 			break;
 	}
 	h->max_huge_pages = i;
@@ -1144,16 +1157,22 @@ static void __init report_hugepages(void
 }
 
 #ifdef CONFIG_HIGHMEM
-static void try_to_free_low(struct hstate *h, unsigned long count)
+static void try_to_free_low(struct hstate *h, unsigned long count,
+						nodemask_t *nodes_allowed)
 {
 	int i;
 
 	if (h->order >= MAX_ORDER)
 		return;
 
+	if (!nodes_allowed)
+		nodes_allowed = &node_online_map;
+
 	for (i = 0; i < MAX_NUMNODES; ++i) {
 		struct page *page, *next;
 		struct list_head *freel = &h->hugepage_freelists[i];
+		if (!node_isset(i, *nodes_allowed))
+			continue;
 		list_for_each_entry_safe(page, next, freel, lru) {
 			if (count >= h->nr_huge_pages)
 				return;
@@ -1167,7 +1186,8 @@ static void try_to_free_low(struct hstat
 	}
 }
 #else
-static inline void try_to_free_low(struct hstate *h, unsigned long count)
+static inline void try_to_free_low(struct hstate *h, unsigned long count,
+						nodemask_t *nodes_allowed)
 {
 }
 #endif
@@ -1177,7 +1197,8 @@ static inline void try_to_free_low(struc
  * balanced by operating on them in a round-robin fashion.
  * Returns 1 if an adjustment was made.
  */
-static int adjust_pool_surplus(struct hstate *h, int delta)
+static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
+				int delta)
 {
 	int start_nid, next_nid;
 	int ret = 0;
@@ -1185,9 +1206,9 @@ static int adjust_pool_surplus(struct hs
 	VM_BUG_ON(delta != -1 && delta != 1);
 
 	if (delta < 0)
-		start_nid = hstate_next_node_to_alloc(h);
+		start_nid = hstate_next_node_to_alloc(h, nodes_allowed);
 	else
-		start_nid = hstate_next_node_to_free(h);
+		start_nid = hstate_next_node_to_free(h, nodes_allowed);
 	next_nid = start_nid;
 
 	do {
@@ -1197,7 +1218,8 @@ static int adjust_pool_surplus(struct hs
 			 * To shrink on this node, there must be a surplus page
 			 */
 			if (!h->surplus_huge_pages_node[nid]) {
-				next_nid = hstate_next_node_to_alloc(h);
+				next_nid = hstate_next_node_to_alloc(h,
+								nodes_allowed);
 				continue;
 			}
 		}
@@ -1207,7 +1229,8 @@ static int adjust_pool_surplus(struct hs
 			 */
 			if (h->surplus_huge_pages_node[nid] >=
 						h->nr_huge_pages_node[nid]) {
-				next_nid = hstate_next_node_to_free(h);
+				next_nid = hstate_next_node_to_free(h,
+								nodes_allowed);
 				continue;
 			}
 		}
@@ -1242,7 +1265,7 @@ static unsigned long set_max_huge_pages(
 	 */
 	spin_lock(&hugetlb_lock);
 	while (h->surplus_huge_pages && count > persistent_huge_pages(h)) {
-		if (!adjust_pool_surplus(h, -1))
+		if (!adjust_pool_surplus(h, NULL, -1))
 			break;
 	}
 
@@ -1253,7 +1276,7 @@ static unsigned long set_max_huge_pages(
 		 * and reducing the surplus.
 		 */
 		spin_unlock(&hugetlb_lock);
-		ret = alloc_fresh_huge_page(h);
+		ret = alloc_fresh_huge_page(h, NULL);
 		spin_lock(&hugetlb_lock);
 		if (!ret)
 			goto out;
@@ -1277,13 +1300,13 @@ static unsigned long set_max_huge_pages(
 	 */
 	min_count = h->resv_huge_pages + h->nr_huge_pages - h->free_huge_pages;
 	min_count = max(count, min_count);
-	try_to_free_low(h, min_count);
+	try_to_free_low(h, min_count, NULL);
 	while (min_count < persistent_huge_pages(h)) {
-		if (!free_pool_huge_page(h, 0))
+		if (!free_pool_huge_page(h, NULL, 0))
 			break;
 	}
 	while (count < persistent_huge_pages(h)) {
-		if (!adjust_pool_surplus(h, 1))
+		if (!adjust_pool_surplus(h, NULL, 1))
 			break;
 	}
 out:

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from task mempolicy
Date: Fri, 28 Aug 2009 12:03:32 -0400
Message-ID: <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

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

Against: 2.6.31-rc7-mmotm-090827-0057

V2:
+ cleaned up comments, removed some deemed unnecessary,
  add some suggested by review
+ removed check for !current in huge_mpol_nodes_allowed().
+ added 'current->comm' to warning message in huge_mpol_nodes_allowed().
+ added VM_BUG_ON() assertion in hugetlb.c next_node_allowed() to
  catch out of range node id.
+ add examples to patch description

V3: Factored this patch from V2 patch 2/3

V4: added back missing "kfree(nodes_allowed)" in set_max_nr_hugepages()

V5: remove internal '\n' from printk in huge_mpol_nodes_allowed()

This patch derives a "nodes_allowed" node mask from the numa
mempolicy of the task modifying the number of persistent huge
pages to control the allocation, freeing and adjusting of surplus
huge pages.  This mask is derived as follows:

* For "default" [NULL] task mempolicy, a NULL nodemask_t pointer
  is produced.  This will cause the hugetlb subsystem to use
  node_online_map as the "nodes_allowed".  This preserves the
  behavior before this patch.
* For "preferred" mempolicy, including explicit local allocation,
  a nodemask with the single preferred node will be produced. 
  "local" policy will NOT track any internode migrations of the
  task adjusting nr_hugepages.
* For "bind" and "interleave" policy, the mempolicy's nodemask
  will be used.
* Other than to inform the construction of the nodes_allowed node
  mask, the actual mempolicy mode is ignored.  That is, all modes
  behave like interleave over the resulting nodes_allowed mask
  with no "fallback".

Notes:

1) This patch introduces a subtle change in behavior:  huge page
   allocation and freeing will be constrained by any mempolicy
   that the task adjusting the huge page pool inherits from its
   parent.  This policy could come from a distant ancestor.  The
   adminstrator adjusting the huge page pool without explicitly
   specifying a mempolicy via numactl might be surprised by this.
   Additionaly, any mempolicy specified by numactl will be
   constrained by the cpuset in which numactl is invoked.
   Using sysfs per node hugepages attributes to adjust the per
   node persistent huge pages count [subsequent patch] ignores
   mempolicy and cpuset constraints.

2) Hugepages allocated at boot time use the node_online_map.
   An additional patch could implement a temporary boot time
   huge pages nodes_allowed command line parameter.

3) Using mempolicy to control persistent huge page allocation
   and freeing requires no change to hugeadm when invoking
   it via numactl, as shown in the examples below.  However,
   hugeadm could be enhanced to take the allowed nodes as an
   argument and set its task mempolicy itself.  This would allow
   it to detect and warn about any non-default mempolicy that it
   inherited from its parent, thus alleviating the issue described
   in Note 1 above.

See the updated documentation [next patch] for more information
about the implications of this patch.

Examples:

Starting with:

	Node 0 HugePages_Total:     0
	Node 1 HugePages_Total:     0
	Node 2 HugePages_Total:     0
	Node 3 HugePages_Total:     0

Default behavior [with or without this patch] balances persistent
hugepage allocation across nodes [with sufficient contiguous memory]:

	hugeadm --pool-pages-min=2048Kb:32

yields:

	Node 0 HugePages_Total:     8
	Node 1 HugePages_Total:     8
	Node 2 HugePages_Total:     8
	Node 3 HugePages_Total:     8

Applying mempolicy--e.g., with numactl [using '-m' a.k.a.
'--membind' because it allows multiple nodes to be specified
and it's easy to type]--we can allocate huge pages on
individual nodes or sets of nodes.  So, starting from the 
condition above, with 8 huge pages per node:

	numactl -m 2 hugeadm --pool-pages-min=2048Kb:+8

yields:

	Node 0 HugePages_Total:     8
	Node 1 HugePages_Total:     8
	Node 2 HugePages_Total:    16
	Node 3 HugePages_Total:     8

The incremental 8 huge pages were restricted to node 2 by the
specified mempolicy.

Similarly, we can use mempolicy to free persistent huge pages
from specified nodes:

	numactl -m 0,1 hugeadm --pool-pages-min=2048Kb:-8

yields:

	Node 0 HugePages_Total:     4
	Node 1 HugePages_Total:     4
	Node 2 HugePages_Total:    16
	Node 3 HugePages_Total:     8

The 8 huge pages freed were balanced over nodes 0 and 1.

Acked-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/mempolicy.h |    3 ++
 mm/hugetlb.c              |   14 ++++++----
 mm/mempolicy.c            |   61 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 73 insertions(+), 5 deletions(-)

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.
+ */
+nodemask_t *huge_mpol_nodes_allowed(void)
+{
+	nodemask_t *nodes_allowed = NULL;
+	struct mempolicy *mempolicy;
+	int nid;
+
+	if (!current->mempolicy)
+		return NULL;
+
+	mpol_get(current->mempolicy);
+	nodes_allowed = kmalloc(sizeof(*nodes_allowed), GFP_KERNEL);
+	if (!nodes_allowed) {
+		printk(KERN_WARNING "%s unable to allocate nodes allowed mask "
+			"for huge page allocation.  Falling back to default.\n",
+			current->comm);
+		goto out;
+	}
+	nodes_clear(*nodes_allowed);
+
+	mempolicy = current->mempolicy;
+	switch (mempolicy->mode) {
+	case MPOL_PREFERRED:
+		if (mempolicy->flags & MPOL_F_LOCAL)
+			nid = numa_node_id();
+		else
+			nid = mempolicy->v.preferred_node;
+		node_set(nid, *nodes_allowed);
+		break;
+
+	case MPOL_BIND:
+		/* Fall through */
+	case MPOL_INTERLEAVE:
+		*nodes_allowed =  mempolicy->v.nodes;
+		break;
+
+	default:
+		BUG();
+	}
+
+out:
+	mpol_put(current->mempolicy);
+	return nodes_allowed;
+}
 #endif
 
 /* Allocate a page in interleaved policy.
Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/mempolicy.h
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/mempolicy.h	2009-08-28 09:21:20.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/mempolicy.h	2009-08-28 09:21:28.000000000 -0400
@@ -201,6 +201,7 @@ extern void mpol_fix_fork_child_flag(str
 extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
 				unsigned long addr, gfp_t gfp_flags,
 				struct mempolicy **mpol, nodemask_t **nodemask);
+extern nodemask_t *huge_mpol_nodes_allowed(void);
 extern unsigned slab_node(struct mempolicy *policy);
 
 extern enum zone_type policy_zone;
@@ -328,6 +329,8 @@ static inline struct zonelist *huge_zone
 	return node_zonelist(0, gfp_flags);
 }
 
+static inline nodemask_t *huge_mpol_nodes_allowed(void) { return NULL; }
+
 static inline int do_migrate_pages(struct mm_struct *mm,
 			const nodemask_t *from_nodes,
 			const nodemask_t *to_nodes, int flags)
Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:26.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
@@ -1248,10 +1248,13 @@ static int adjust_pool_surplus(struct hs
 static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
 {
 	unsigned long min_count, ret;
+	nodemask_t *nodes_allowed;
 
 	if (h->order >= MAX_ORDER)
 		return h->max_huge_pages;
 
+	nodes_allowed = huge_mpol_nodes_allowed();
+
 	/*
 	 * Increase the pool size
 	 * First take pages out of surplus state.  Then make up the
@@ -1265,7 +1268,7 @@ static unsigned long set_max_huge_pages(
 	 */
 	spin_lock(&hugetlb_lock);
 	while (h->surplus_huge_pages && count > persistent_huge_pages(h)) {
-		if (!adjust_pool_surplus(h, NULL, -1))
+		if (!adjust_pool_surplus(h, nodes_allowed, -1))
 			break;
 	}
 
@@ -1276,7 +1279,7 @@ static unsigned long set_max_huge_pages(
 		 * and reducing the surplus.
 		 */
 		spin_unlock(&hugetlb_lock);
-		ret = alloc_fresh_huge_page(h, NULL);
+		ret = alloc_fresh_huge_page(h, nodes_allowed);
 		spin_lock(&hugetlb_lock);
 		if (!ret)
 			goto out;
@@ -1300,18 +1303,19 @@ static unsigned long set_max_huge_pages(
 	 */
 	min_count = h->resv_huge_pages + h->nr_huge_pages - h->free_huge_pages;
 	min_count = max(count, min_count);
-	try_to_free_low(h, min_count, NULL);
+	try_to_free_low(h, min_count, nodes_allowed);
 	while (min_count < persistent_huge_pages(h)) {
-		if (!free_pool_huge_page(h, NULL, 0))
+		if (!free_pool_huge_page(h, nodes_allowed, 0))
 			break;
 	}
 	while (count < persistent_huge_pages(h)) {
-		if (!adjust_pool_surplus(h, NULL, 1))
+		if (!adjust_pool_surplus(h, nodes_allowed, 1))
 			break;
 	}
 out:
 	ret = persistent_huge_pages(h);
 	spin_unlock(&hugetlb_lock);
+	kfree(nodes_allowed);
 	return ret;
 }
 

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
Date: Fri, 28 Aug 2009 12:03:38 -0400
Message-ID: <20090828160338.11080.51282.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

[PATCH 4/6] - hugetlb:  introduce alloc_nodemask_of_node()

Against:  2.6.31-rc7-mmotm-090827-0057

New in V5 of series

Introduce nodemask macro to allocate a nodemask and 
initialize it to contain a single node, using the macro
init_nodemask_of_node() factored out of the nodemask_of_node()
macro.

alloc_nodemask_of_node() coded as a macro to avoid header
dependency hell.

This will be used to construct the huge pages "nodes_allowed"
nodemask for a single node when a persistent huge page
pool page count is modified via a per node sysfs attribute.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/nodemask.h |   20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h	2009-08-28 09:21:19.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h	2009-08-28 09:21:29.000000000 -0400
@@ -245,18 +245,34 @@ static inline int __next_node(int n, con
 	return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
 }
 
+#define init_nodemask_of_nodes(mask, node)				\
+	nodes_clear(*(mask));						\
+	node_set((node), *(mask));
+
 #define nodemask_of_node(node)						\
 ({									\
 	typeof(_unused_nodemask_arg_) m;				\
 	if (sizeof(m) == sizeof(unsigned long)) {			\
 		m.bits[0] = 1UL<<(node);				\
 	} else {							\
-		nodes_clear(m);						\
-		node_set((node), m);					\
+		init_nodemask_of_nodes(&m, (node));			\
 	}								\
 	m;								\
 })
 
+/*
+ * returns pointer to kmalloc()'d nodemask initialized to contain the
+ * specified node.  Caller must free with kfree().
+ */
+#define alloc_nodemask_of_node(node)					\
+({									\
+	typeof(_unused_nodemask_arg_) *nmp;				\
+	nmp = kmalloc(sizeof(*nmp), GFP_KERNEL);			\
+	if (nmp)							\
+		init_nodemask_of_nodes(nmp, (node));			\
+	nmp;								\
+})
+
 #define first_unset_node(mask) __first_unset_node(&(mask))
 static inline int __first_unset_node(const nodemask_t *maskp)
 {

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: [PATCH 5/6] hugetlb:  add per node hstate attributes
Date: Fri, 28 Aug 2009 12:03:44 -0400
Message-ID: <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

[PATCH 5/6] hugetlb:  register per node hugepages attributes

Against: 2.6.31-rc7-mmotm-090820-1918

V2:  remove dependency on kobject private bitfield.  Search
     global hstates then all per node hstates for kobject
     match in attribute show/store functions.

V3:  rebase atop the mempolicy-based hugepage alloc/free;
     use custom "nodes_allowed" to restrict alloc/free to
     a specific node via per node attributes.  Per node
     attribute overrides mempolicy.  I.e., mempolicy only
     applies to global attributes.

V5:  Fix issues raised by Mel Gorman:
     + add !NUMA versions of hugetlb_[un]register_node()
     + rename 'hi' to 'i' in kobj_to_node_hstate()
     + rename (count, input) to (len, count) in nr_hugepages_store()
     + moved per node hugepages_kobj and hstate_kobjs[] from the
       struct node [sysdev] to hugetlb.c private arrays.
     + changed registration mechanism so that hugetlbfs [a module]
       register its attributes registration callbacks with the node
       driver, eliminating the dependency between the node driver
       and hugetlbfs.  From it's init func, hugetlbfs will register
       all on-line nodes' hugepage sysfs attributes along with
       hugetlbfs' attributes register/unregister functions.  The
       node driver will use these functions to [un]register nodes
       with hugetlbfs on node hot-plug.
     + replaced hugetlb.c private "nodes_allowed_from_node()" with
       [new] generic "alloc_nodemask_of_node()".

V5a: + fix !NUMA register_hugetlbfs_with_node():  don't use
       keyword 'do' as parameter name!

This patch adds the per huge page size control/query attributes
to the per node sysdevs:

/sys/devices/system/node/node<ID>/hugepages/hugepages-<size>/
	nr_hugepages       - r/w
	free_huge_pages    - r/o
	surplus_huge_pages - r/o

The patch attempts to re-use/share as much of the existing
global hstate attribute initialization and handling, and the
"nodes_allowed" constraint processing as possible.
Calling set_max_huge_pages() with no node indicates a change to
global hstate parameters.  In this case, any non-default task
mempolicy will be used to generate the nodes_allowed mask.  A
valid node id indicates an update to that node's hstate 
parameters, and the count argument specifies the target count
for the specified node.  From this info, we compute the target
global count for the hstate and construct a nodes_allowed node
mask contain only the specified node.

Setting the node specific nr_hugepages via the per node attribute
effectively ignores any task mempolicy or cpuset constraints.

With this patch:

(me):ls /sys/devices/system/node/node0/hugepages/hugepages-2048kB
./  ../  free_hugepages  nr_hugepages  surplus_hugepages

Starting from:
Node 0 HugePages_Total:     0
Node 0 HugePages_Free:      0
Node 0 HugePages_Surp:      0
Node 1 HugePages_Total:     0
Node 1 HugePages_Free:      0
Node 1 HugePages_Surp:      0
Node 2 HugePages_Total:     0
Node 2 HugePages_Free:      0
Node 2 HugePages_Surp:      0
Node 3 HugePages_Total:     0
Node 3 HugePages_Free:      0
Node 3 HugePages_Surp:      0
vm.nr_hugepages = 0

Allocate 16 persistent huge pages on node 2:
(me):echo 16 >/sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages

[Note that this is equivalent to:
	numactl -m 2 hugeadmin --pool-pages-min 2M:+16
]

Yields:
Node 0 HugePages_Total:     0
Node 0 HugePages_Free:      0
Node 0 HugePages_Surp:      0
Node 1 HugePages_Total:     0
Node 1 HugePages_Free:      0
Node 1 HugePages_Surp:      0
Node 2 HugePages_Total:    16
Node 2 HugePages_Free:     16
Node 2 HugePages_Surp:      0
Node 3 HugePages_Total:     0
Node 3 HugePages_Free:      0
Node 3 HugePages_Surp:      0
vm.nr_hugepages = 16

Global controls work as expected--reduce pool to 8 persistent huge pages:
(me):echo 8 >/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

Node 0 HugePages_Total:     0
Node 0 HugePages_Free:      0
Node 0 HugePages_Surp:      0
Node 1 HugePages_Total:     0
Node 1 HugePages_Free:      0
Node 1 HugePages_Surp:      0
Node 2 HugePages_Total:     8
Node 2 HugePages_Free:      8
Node 2 HugePages_Surp:      0
Node 3 HugePages_Total:     0
Node 3 HugePages_Free:      0
Node 3 HugePages_Surp:      0

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 drivers/base/node.c  |   33 ++++++
 include/linux/node.h |    8 +
 include/linux/numa.h |    2 
 mm/hugetlb.c         |  245 ++++++++++++++++++++++++++++++++++++++++++++-------
 4 files changed, 258 insertions(+), 30 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/drivers/base/node.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/drivers/base/node.c	2009-08-28 09:21:17.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/drivers/base/node.c	2009-08-28 09:21:31.000000000 -0400
@@ -177,6 +177,37 @@ static ssize_t node_read_distance(struct
 }
 static SYSDEV_ATTR(distance, S_IRUGO, node_read_distance, NULL);
 
+/*
+ * hugetlbfs per node attributes registration interface:
+ * When/if hugetlb[fs] subsystem initializes [sometime after this module],
+ * it will register it's per node attributes for all nodes on-line at that
+ * point.  It will also call register_hugetlbfs_with_node(), below, to
+ * register it's attribute registration functions with this node driver.
+ * Once these hooks have been initialized, the node driver will call into
+ * the hugetlb module to [un]register attributes for hot-plugged nodes.
+ */
+NODE_REGISTRATION_FUNC __hugetlb_register_node;
+NODE_REGISTRATION_FUNC __hugetlb_unregister_node;
+
+static inline void hugetlb_register_node(struct node *node)
+{
+	if (__hugetlb_register_node)
+		__hugetlb_register_node(node);
+}
+
+static inline void hugetlb_unregister_node(struct node *node)
+{
+	if (__hugetlb_unregister_node)
+		__hugetlb_unregister_node(node);
+}
+
+void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC doregister,
+                                  NODE_REGISTRATION_FUNC unregister)
+{
+	__hugetlb_register_node   = doregister;
+	__hugetlb_unregister_node = unregister;
+}
+
 
 /*
  * register_node - Setup a sysfs device for a node.
@@ -200,6 +231,7 @@ int register_node(struct node *node, int
 		sysdev_create_file(&node->sysdev, &attr_distance);
 
 		scan_unevictable_register_node(node);
+		hugetlb_register_node(node);
 	}
 	return error;
 }
@@ -220,6 +252,7 @@ void unregister_node(struct node *node)
 	sysdev_remove_file(&node->sysdev, &attr_distance);
 
 	scan_unevictable_unregister_node(node);
+	hugetlb_unregister_node(node);
 
 	sysdev_unregister(&node->sysdev);
 }
Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:31.000000000 -0400
@@ -24,6 +24,7 @@
 #include <asm/io.h>
 
 #include <linux/hugetlb.h>
+#include <linux/node.h>
 #include "internal.h"
 
 const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
@@ -1245,7 +1246,8 @@ static int adjust_pool_surplus(struct hs
 }
 
 #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
-static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
+static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
+								int nid)
 {
 	unsigned long min_count, ret;
 	nodemask_t *nodes_allowed;
@@ -1253,7 +1255,21 @@ static unsigned long set_max_huge_pages(
 	if (h->order >= MAX_ORDER)
 		return h->max_huge_pages;
 
-	nodes_allowed = huge_mpol_nodes_allowed();
+	if (nid == NO_NODEID_SPECIFIED)
+		nodes_allowed = huge_mpol_nodes_allowed();
+	else {
+		/*
+		 * incoming 'count' is for node 'nid' only, so
+		 * adjust count to global, but restrict alloc/free
+		 * to the specified node.
+		 */
+		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
+		nodes_allowed = alloc_nodemask_of_node(nid);
+		if (!nodes_allowed)
+			printk(KERN_WARNING "%s unable to allocate allowed "
+			       "nodes mask for huge page allocation/free.  "
+			       "Falling back to default.\n", current->comm);
+	}
 
 	/*
 	 * Increase the pool size
@@ -1329,51 +1345,71 @@ out:
 static struct kobject *hugepages_kobj;
 static struct kobject *hstate_kobjs[HUGE_MAX_HSTATE];
 
-static struct hstate *kobj_to_hstate(struct kobject *kobj)
+static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp);
+
+static struct hstate *kobj_to_hstate(struct kobject *kobj, int *nidp)
 {
 	int i;
+
 	for (i = 0; i < HUGE_MAX_HSTATE; i++)
-		if (hstate_kobjs[i] == kobj)
+		if (hstate_kobjs[i] == kobj) {
+			if (nidp)
+				*nidp = NO_NODEID_SPECIFIED;
 			return &hstates[i];
-	BUG();
-	return NULL;
+		}
+
+	return kobj_to_node_hstate(kobj, nidp);
 }
 
 static ssize_t nr_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
-	return sprintf(buf, "%lu\n", h->nr_huge_pages);
+	struct hstate *h;
+	unsigned long nr_huge_pages;
+	int nid;
+
+	h = kobj_to_hstate(kobj, &nid);
+	if (nid == NO_NODEID_SPECIFIED)
+		nr_huge_pages = h->nr_huge_pages;
+	else
+		nr_huge_pages = h->nr_huge_pages_node[nid];
+
+	return sprintf(buf, "%lu\n", nr_huge_pages);
 }
+
 static ssize_t nr_hugepages_store(struct kobject *kobj,
-		struct kobj_attribute *attr, const char *buf, size_t count)
+		struct kobj_attribute *attr, const char *buf, size_t len)
 {
+	unsigned long count;
+	struct hstate *h;
+	int nid;
 	int err;
-	unsigned long input;
-	struct hstate *h = kobj_to_hstate(kobj);
 
-	err = strict_strtoul(buf, 10, &input);
+	err = strict_strtoul(buf, 10, &count);
 	if (err)
 		return 0;
 
-	h->max_huge_pages = set_max_huge_pages(h, input);
+	h = kobj_to_hstate(kobj, &nid);
+	h->max_huge_pages = set_max_huge_pages(h, count, nid);
 
-	return count;
+	return len;
 }
 HSTATE_ATTR(nr_hugepages);
 
 static ssize_t nr_overcommit_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
+	struct hstate *h = kobj_to_hstate(kobj, NULL);
+
 	return sprintf(buf, "%lu\n", h->nr_overcommit_huge_pages);
 }
+
 static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
 		struct kobj_attribute *attr, const char *buf, size_t count)
 {
 	int err;
 	unsigned long input;
-	struct hstate *h = kobj_to_hstate(kobj);
+	struct hstate *h = kobj_to_hstate(kobj, NULL);
 
 	err = strict_strtoul(buf, 10, &input);
 	if (err)
@@ -1390,15 +1426,24 @@ HSTATE_ATTR(nr_overcommit_hugepages);
 static ssize_t free_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
-	return sprintf(buf, "%lu\n", h->free_huge_pages);
+	struct hstate *h;
+	unsigned long free_huge_pages;
+	int nid;
+
+	h = kobj_to_hstate(kobj, &nid);
+	if (nid == NO_NODEID_SPECIFIED)
+		free_huge_pages = h->free_huge_pages;
+	else
+		free_huge_pages = h->free_huge_pages_node[nid];
+
+	return sprintf(buf, "%lu\n", free_huge_pages);
 }
 HSTATE_ATTR_RO(free_hugepages);
 
 static ssize_t resv_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
+	struct hstate *h = kobj_to_hstate(kobj, NULL);
 	return sprintf(buf, "%lu\n", h->resv_huge_pages);
 }
 HSTATE_ATTR_RO(resv_hugepages);
@@ -1406,8 +1451,17 @@ HSTATE_ATTR_RO(resv_hugepages);
 static ssize_t surplus_hugepages_show(struct kobject *kobj,
 					struct kobj_attribute *attr, char *buf)
 {
-	struct hstate *h = kobj_to_hstate(kobj);
-	return sprintf(buf, "%lu\n", h->surplus_huge_pages);
+	struct hstate *h;
+	unsigned long surplus_huge_pages;
+	int nid;
+
+	h = kobj_to_hstate(kobj, &nid);
+	if (nid == NO_NODEID_SPECIFIED)
+		surplus_huge_pages = h->surplus_huge_pages;
+	else
+		surplus_huge_pages = h->surplus_huge_pages_node[nid];
+
+	return sprintf(buf, "%lu\n", surplus_huge_pages);
 }
 HSTATE_ATTR_RO(surplus_hugepages);
 
@@ -1424,19 +1478,21 @@ static struct attribute_group hstate_att
 	.attrs = hstate_attrs,
 };
 
-static int __init hugetlb_sysfs_add_hstate(struct hstate *h)
+static int __init hugetlb_sysfs_add_hstate(struct hstate *h,
+				struct kobject *parent,
+				struct kobject **hstate_kobjs,
+				struct attribute_group *hstate_attr_group)
 {
 	int retval;
+	int hi = h - hstates;
 
-	hstate_kobjs[h - hstates] = kobject_create_and_add(h->name,
-							hugepages_kobj);
-	if (!hstate_kobjs[h - hstates])
+	hstate_kobjs[hi] = kobject_create_and_add(h->name, parent);
+	if (!hstate_kobjs[hi])
 		return -ENOMEM;
 
-	retval = sysfs_create_group(hstate_kobjs[h - hstates],
-							&hstate_attr_group);
+	retval = sysfs_create_group(hstate_kobjs[hi], hstate_attr_group);
 	if (retval)
-		kobject_put(hstate_kobjs[h - hstates]);
+		kobject_put(hstate_kobjs[hi]);
 
 	return retval;
 }
@@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
 		return;
 
 	for_each_hstate(h) {
-		err = hugetlb_sysfs_add_hstate(h);
+		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
+					 hstate_kobjs, &hstate_attr_group);
 		if (err)
 			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
 								h->name);
 	}
 }
 
+#ifdef CONFIG_NUMA
+
+struct node_hstate {
+	struct kobject		*hugepages_kobj;
+	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
+};
+struct node_hstate node_hstates[MAX_NUMNODES];
+
+static struct attribute *per_node_hstate_attrs[] = {
+	&nr_hugepages_attr.attr,
+	&free_hugepages_attr.attr,
+	&surplus_hugepages_attr.attr,
+	NULL,
+};
+
+static struct attribute_group per_node_hstate_attr_group = {
+	.attrs = per_node_hstate_attrs,
+};
+
+static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
+{
+	int nid;
+
+	for (nid = 0; nid < nr_node_ids; nid++) {
+		struct node_hstate *nhs = &node_hstates[nid];
+		int i;
+		for (i = 0; i < HUGE_MAX_HSTATE; i++)
+			if (nhs->hstate_kobjs[i] == kobj) {
+				if (nidp)
+					*nidp = nid;
+				return &hstates[i];
+			}
+	}
+
+	BUG();
+	return NULL;
+}
+
+void hugetlb_unregister_node(struct node *node)
+{
+	struct hstate *h;
+	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
+
+	if (!nhs->hugepages_kobj)
+		return;
+
+	for_each_hstate(h)
+		if (nhs->hstate_kobjs[h - hstates]) {
+			kobject_put(nhs->hstate_kobjs[h - hstates]);
+			nhs->hstate_kobjs[h - hstates] = NULL;
+		}
+
+	kobject_put(nhs->hugepages_kobj);
+	nhs->hugepages_kobj = NULL;
+}
+
+static void hugetlb_unregister_all_nodes(void)
+{
+	int nid;
+
+	for (nid = 0; nid < nr_node_ids; nid++)
+		hugetlb_unregister_node(&node_devices[nid]);
+
+	register_hugetlbfs_with_node(NULL, NULL);
+}
+
+void hugetlb_register_node(struct node *node)
+{
+	struct hstate *h;
+	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
+	int err;
+
+	if (nhs->hugepages_kobj)
+		return;		/* already allocated */
+
+	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
+							&node->sysdev.kobj);
+	if (!nhs->hugepages_kobj)
+		return;
+
+	for_each_hstate(h) {
+		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
+						nhs->hstate_kobjs,
+						&per_node_hstate_attr_group);
+		if (err) {
+			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
+					" for node %d\n",
+						h->name, node->sysdev.id);
+			hugetlb_unregister_node(node);
+			break;
+		}
+	}
+}
+
+static void hugetlb_register_all_nodes(void)
+{
+	int nid;
+
+	for (nid = 0; nid < nr_node_ids; nid++) {
+		struct node *node = &node_devices[nid];
+		if (node->sysdev.id == nid)
+			hugetlb_register_node(node);
+	}
+
+	register_hugetlbfs_with_node(hugetlb_register_node,
+                                     hugetlb_unregister_node);
+}
+#else	/* !CONFIG_NUMA */
+
+static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
+{
+	BUG();
+	if (nidp)
+		*nidp = -1;
+	return NULL;
+}
+
+static void hugetlb_unregister_all_nodes(void) { }
+
+static void hugetlb_register_all_nodes(void) { }
+
+#endif
+
 static void __exit hugetlb_exit(void)
 {
 	struct hstate *h;
 
+	hugetlb_unregister_all_nodes();
+
 	for_each_hstate(h) {
 		kobject_put(hstate_kobjs[h - hstates]);
 	}
@@ -1496,6 +1678,8 @@ static int __init hugetlb_init(void)
 
 	hugetlb_sysfs_init();
 
+	hugetlb_register_all_nodes();
+
 	return 0;
 }
 module_init(hugetlb_init);
@@ -1598,7 +1782,8 @@ int hugetlb_sysctl_handler(struct ctl_ta
 	proc_doulongvec_minmax(table, write, buffer, length, ppos);
 
 	if (write)
-		h->max_huge_pages = set_max_huge_pages(h, tmp);
+		h->max_huge_pages = set_max_huge_pages(h, tmp,
+		                                       NO_NODEID_SPECIFIED);
 
 	return 0;
 }
Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
@@ -10,4 +10,6 @@
 
 #define MAX_NUMNODES    (1 << NODES_SHIFT)
 
+#define NO_NODEID_SPECIFIED	(-1)
+
 #endif /* _LINUX_NUMA_H */
Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/node.h
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/node.h	2009-08-28 09:21:17.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/node.h	2009-08-28 09:21:31.000000000 -0400
@@ -28,6 +28,7 @@ struct node {
 
 struct memory_block;
 extern struct node node_devices[];
+typedef  void (*NODE_REGISTRATION_FUNC)(struct node *);
 
 extern int register_node(struct node *, int, struct node *);
 extern void unregister_node(struct node *node);
@@ -39,6 +40,8 @@ extern int unregister_cpu_under_node(uns
 extern int register_mem_sect_under_node(struct memory_block *mem_blk,
 						int nid);
 extern int unregister_mem_sect_under_nodes(struct memory_block *mem_blk);
+extern void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC doregister,
+                                         NODE_REGISTRATION_FUNC unregister);
 #else
 static inline int register_one_node(int nid)
 {
@@ -65,6 +68,11 @@ static inline int unregister_mem_sect_un
 {
 	return 0;
 }
+
+static inline void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC reg,
+                                                NODE_REGISTRATION_FUNC unreg)
+{
+}
 #endif
 
 #define to_node(sys_device) container_of(sys_device, struct node, sysdev)

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy based management.
Date: Fri, 28 Aug 2009 12:03:51 -0400
Message-ID: <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

[PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy based management.

Against: 2.6.31-rc7-mmotm-090827-0057

V2:  Add brief description of per node attributes.

This patch updates the kernel huge tlb documentation to describe the
numa memory policy based huge page management.  Additionaly, the patch
includes a fair amount of rework to improve consistency, eliminate
duplication and set the context for documenting the memory policy
interaction.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 Documentation/vm/hugetlbpage.txt |  257 ++++++++++++++++++++++++++-------------
 1 file changed, 172 insertions(+), 85 deletions(-)

Index: linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt
===================================================================
--- linux-2.6.31-rc7-mmotm-090827-0057.orig/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:16.000000000 -0400
+++ linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:32.000000000 -0400
@@ -11,23 +11,21 @@ This optimization is more critical now a
 (several GBs) are more readily available.
 
 Users can use the huge page support in Linux kernel by either using the mmap
-system call or standard SYSv shared memory system calls (shmget, shmat).
+system call or standard SYSV shared memory system calls (shmget, shmat).
 
 First the Linux kernel needs to be built with the CONFIG_HUGETLBFS
 (present under "File systems") and CONFIG_HUGETLB_PAGE (selected
 automatically when CONFIG_HUGETLBFS is selected) configuration
 options.
 
-The kernel built with huge page support should show the number of configured
-huge pages in the system by running the "cat /proc/meminfo" command.
+The /proc/meminfo file provides information about the total number of hugetlb
+pages preallocated in the kernel's huge page pool.  It also displays
+information about the number of free, reserved and surplus huge pages and the
+[default] huge page size.  The huge page size is needed for generating the
+proper alignment and size of the arguments to system calls that map huge page
+regions.
 
-/proc/meminfo also provides information about the total number of hugetlb
-pages configured in the kernel.  It also displays information about the
-number of free hugetlb pages at any time.  It also displays information about
-the configured huge page size - this is needed for generating the proper
-alignment and size of the arguments to the above system calls.
-
-The output of "cat /proc/meminfo" will have lines like:
+The output of "cat /proc/meminfo" will include lines like:
 
 .....
 HugePages_Total: vvv
@@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
 /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
 in the kernel.
 
-/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
-pages in the kernel.  Super user can dynamically request more (or free some
-pre-configured) huge pages.
-The allocation (or deallocation) of hugetlb pages is possible only if there are
-enough physically contiguous free pages in system (freeing of huge pages is
-possible only if there are enough hugetlb pages free that can be transferred
-back to regular memory pool).
-
-Pages that are used as hugetlb pages are reserved inside the kernel and cannot
-be used for other purposes.
-
-Once the kernel with Hugetlb page support is built and running, a user can
-use either the mmap system call or shared memory system calls to start using
-the huge pages.  It is required that the system administrator preallocate
-enough memory for huge page purposes.
-
-The administrator can preallocate huge pages on the kernel boot command line by
-specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
-requested.  This is the most reliable method for preallocating huge pages as
-memory has not yet become fragmented.
+/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
+allocated in the kernel's huge page pool.  These are called "persistent"
+huge pages.  A user with root privileges can dynamically allocate more or
+free some persistent huge pages by increasing or decreasing the value of
+'nr_hugepages'.
+
+Pages that are used as huge pages are reserved inside the kernel and cannot
+be used for other purposes.  Huge pages can not be swapped out under
+memory pressure.
+
+Once a number of huge pages have been pre-allocated to the kernel huge page
+pool, a user with appropriate privilege can use either the mmap system call
+or shared memory system calls to use the huge pages.  See the discussion of
+Using Huge Pages, below
+
+The administrator can preallocate persistent huge pages on the kernel boot
+command line by specifying the "hugepages=N" parameter, where 'N' = the
+number of requested huge pages requested.  This is the most reliable method
+or preallocating huge pages as memory has not yet become fragmented.
 
 Some platforms support multiple huge page sizes.  To preallocate huge pages
 of a specific size, one must preceed the huge pages boot command parameters
@@ -80,19 +77,24 @@ with a huge page size selection paramete
 be specified in bytes with optional scale suffix [kKmMgG].  The default huge
 page size may be selected with the "default_hugepagesz=<size>" boot parameter.
 
-/proc/sys/vm/nr_hugepages indicates the current number of configured [default
-size] hugetlb pages in the kernel.  Super user can dynamically request more
-(or free some pre-configured) huge pages.
-
-Use the following command to dynamically allocate/deallocate default sized
-huge pages:
+When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages
+indicates the current number of pre-allocated huge pages of the default size.
+Thus, one can use the following command to dynamically allocate/deallocate
+default sized persistent huge pages:
 
 	echo 20 > /proc/sys/vm/nr_hugepages
 
-This command will try to configure 20 default sized huge pages in the system.
+This command will try to adjust the number of default sized huge pages in the
+huge page pool to 20, allocating or freeing huge pages, as required.
+
 On a NUMA platform, the kernel will attempt to distribute the huge page pool
-over the all on-line nodes.  These huge pages, allocated when nr_hugepages
-is increased, are called "persistent huge pages".
+over the all the nodes specified by the NUMA memory policy of the task that
+modifies nr_hugepages that contain sufficient available contiguous memory.
+These nodes are called the huge pages "allowed nodes".  The default for the
+huge pages allowed nodes--when the task has default memory policy--is all
+on-line nodes.  See the discussion below of the interaction of task memory
+policy, cpusets and per node attributes with the allocation and freeing of
+persistent huge pages.
 
 The success or failure of huge page allocation depends on the amount of
 physically contiguous memory that is preset in system at the time of the
@@ -101,11 +103,11 @@ some nodes in a NUMA system, it will att
 allocating extra pages on other nodes with sufficient available contiguous
 memory, if any.
 
-System administrators may want to put this command in one of the local rc init
-files.  This will enable the kernel to request huge pages early in the boot
-process when the possibility of getting physical contiguous pages is still
-very high.  Administrators can verify the number of huge pages actually
-allocated by checking the sysctl or meminfo.  To check the per node
+System administrators may want to put this command in one of the local rc
+init files.  This will enable the kernel to preallocate huge pages early in
+the boot process when the possibility of getting physical contiguous pages
+is still very high.  Administrators can verify the number of huge pages
+actually allocated by checking the sysctl or meminfo.  To check the per node
 distribution of huge pages in a NUMA system, use:
 
 	cat /sys/devices/system/node/node*/meminfo | fgrep Huge
@@ -113,39 +115,40 @@ distribution of huge pages in a NUMA sys
 /proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of
 huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are
 requested by applications.  Writing any non-zero value into this file
-indicates that the hugetlb subsystem is allowed to try to obtain "surplus"
-huge pages from the buddy allocator, when the normal pool is exhausted. As
-these surplus huge pages go out of use, they are freed back to the buddy
-allocator.
+indicates that the hugetlb subsystem is allowed to try to obtain that
+number of "surplus" huge pages from the kernel's normal page pool, when the
+persistent huge page pool is exhausted. As these surplus huge pages become
+unused, they are freed back to the kernel's normal page pool.
 
-When increasing the huge page pool size via nr_hugepages, any surplus
+When increasing the huge page pool size via nr_hugepages, any existing surplus
 pages will first be promoted to persistent huge pages.  Then, additional
 huge pages will be allocated, if necessary and if possible, to fulfill
-the new huge page pool size.
+the new persistent huge page pool size.
 
 The administrator may shrink the pool of preallocated huge pages for
 the default huge page size by setting the nr_hugepages sysctl to a
 smaller value.  The kernel will attempt to balance the freeing of huge pages
-across all on-line nodes.  Any free huge pages on the selected nodes will
-be freed back to the buddy allocator.
-
-Caveat: Shrinking the pool via nr_hugepages such that it becomes less
-than the number of huge pages in use will convert the balance to surplus
-huge pages even if it would exceed the overcommit value.  As long as
-this condition holds, however, no more surplus huge pages will be
-allowed on the system until one of the two sysctls are increased
-sufficiently, or the surplus huge pages go out of use and are freed.
+across all nodes in the memory policy of the task modifying nr_hugepages.
+Any free huge pages on the selected nodes will be freed back to the kernel's
+normal page pool.
+
+Caveat: Shrinking the persistent huge page pool via nr_hugepages such that
+it becomes less than the number of huge pages in use will convert the balance
+of the in-use huge pages to surplus huge pages.  This will occur even if
+the number of surplus pages it would exceed the overcommit value.  As long as
+this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is
+increased sufficiently, or the surplus huge pages go out of use and are freed--
+no more surplus huge pages will be allowed to be allocated.
 
 With support for multiple huge page pools at run-time available, much of
-the huge page userspace interface has been duplicated in sysfs. The above
-information applies to the default huge page size which will be
-controlled by the /proc interfaces for backwards compatibility. The root
-huge page control directory in sysfs is:
+the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs.
+The /proc interfaces discussed above have been retained for backwards
+compatibility. The root huge page control directory in sysfs is:
 
 	/sys/kernel/mm/hugepages
 
 For each huge page size supported by the running kernel, a subdirectory
-will exist, of the form
+will exist, of the form:
 
 	hugepages-${size}kB
 
@@ -159,6 +162,98 @@ Inside each of these directories, the sa
 
 which function as described above for the default huge page-sized case.
 
+
+Interaction of Task Memory Policy with Huge Page Allocation/Freeing:
+
+Whether huge pages are allocated and freed via the /proc interface or
+the /sysfs interface, the NUMA nodes from which huge pages are allocated
+or freed are controlled by the NUMA memory policy of the task that modifies
+the nr_hugepages parameter.  [nr_overcommit_hugepages is a global limit.]
+
+The recommended method to allocate or free huge pages to/from the kernel
+huge page pool, using the nr_hugepages example above, is:
+
+    numactl --interleave <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
+
+or, more succinctly:
+
+    numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
+
+This will allocate or free abs(20 - nr_hugepages) to or from the nodes
+specified in <node-list>, depending on whether nr_hugepages is initially
+less than or greater than 20, respectively.  No huge pages will be
+allocated nor freed on any node not included in the specified <node-list>.
+
+Any memory policy mode--bind, preferred, local or interleave--may be
+used.  The effect on persistent huge page allocation will be as follows:
+
+1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt],
+   persistent huge pages will be distributed across the node or nodes
+   specified in the mempolicy as if "interleave" had been specified.
+   However, if a node in the policy does not contain sufficient contiguous
+   memory for a huge page, the allocation will not "fallback" to the nearest
+   neighbor node with sufficient contiguous memory.  To do this would cause
+   undesirable imbalance in the distribution of the huge page pool, or
+   possibly, allocation of persistent huge pages on nodes not allowed by
+   the task's memory policy.
+
+2) One or more nodes may be specified with the bind or interleave policy.
+   If more than one node is specified with the preferred policy, only the
+   lowest numeric id will be used.  Local policy will select the node where
+   the task is running at the time the nodes_allowed mask is constructed.
+
+3) For local policy to be deterministic, the task must be bound to a cpu or
+   cpus in a single node.  Otherwise, the task could be migrated to some
+   other node at any time after launch and the resulting node will be
+   indeterminate.  Thus, local policy is not very useful for this purpose.
+   Any of the other mempolicy modes may be used to specify a single node.
+
+4) The nodes allowed mask will be derived from any non-default task mempolicy,
+   whether this policy was set explicitly by the task itself or one of its
+   ancestors, such as numactl.  This means that if the task is invoked from a
+   shell with non-default policy, that policy will be used.  One can specify a
+   node list of "all" with numactl --interleave or --membind [-m] to achieve
+   interleaving over all nodes in the system or cpuset.
+
+5) Any task mempolicy specifed--e.g., using numactl--will be constrained by
+   the resource limits of any cpuset in which the task runs.  Thus, there will
+   be no way for a task with non-default policy running in a cpuset with a
+   subset of the system nodes to allocate huge pages outside the cpuset
+   without first moving to a cpuset that contains all of the desired nodes.
+
+6) Hugepages allocated at boot time always use the node_online_map.
+
+
+Per Node Hugepages Attributes
+
+A subset of the contents of the root huge page control directory in sysfs,
+described above, has been replicated under each "node" system device in:
+
+	/sys/devices/system/node/node[0-9]*/hugepages/
+
+Under this directory, the subdirectory for each supported huge page size
+contains the following attribute files:
+
+	nr_hugepages
+	free_hugepages
+	surplus_hugepages
+
+The free_' and surplus_' attribute files are read-only.  They return the number
+of free and surplus [overcommitted] huge pages, respectively, on the parent
+node.
+
+The nr_hugepages attribute will return the total number of huge pages on the
+specified node.  When this attribute is written, the number of persistent huge
+pages on the parent node will be adjusted to the specified value, if sufficient
+resources exist, regardless of the task's mempolicy or cpuset constraints.
+
+Note that the number of overcommit and reserve pages remain global quantities,
+as we don't know until fault time, when the faulting task's mempolicy is applied,
+from which node the huge page allocation will be attempted.
+
+
+Using Huge Pages:
+
 If the user applications are going to request huge pages using mmap system
 call, then it is required that system administrator mount a file system of
 type hugetlbfs:
@@ -206,9 +301,11 @@ map_hugetlb.c.
  * requesting huge pages.
  *
  * For the ia64 architecture, the Linux kernel reserves Region number 4 for
- * huge pages.  That means the addresses starting with 0x800000... will need
- * to be specified.  Specifying a fixed address is not required on ppc64,
- * i386 or x86_64.
+ * huge pages.  That means that if one requires a fixed address, a huge page
+ * aligned address starting with 0x800000... will be required.  If a fixed
+ * address is not required, the kernel will select an address in the proper
+ * range.
+ * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
  *
  * Note: The default shared memory limit is quite low on many kernels,
  * you may need to increase it via:
@@ -237,14 +334,8 @@ map_hugetlb.c.
 
 #define dprintf(x)  printf(x)
 
-/* Only ia64 requires this */
-#ifdef __ia64__
-#define ADDR (void *)(0x8000000000000000UL)
-#define SHMAT_FLAGS (SHM_RND)
-#else
-#define ADDR (void *)(0x0UL)
+#define ADDR (void *)(0x0UL)	/* let kernel choose address */
 #define SHMAT_FLAGS (0)
-#endif
 
 int main(void)
 {
@@ -302,10 +393,12 @@ int main(void)
  * example, the app is requesting memory of size 256MB that is backed by
  * huge pages.
  *
- * For ia64 architecture, Linux kernel reserves Region number 4 for huge pages.
- * That means the addresses starting with 0x800000... will need to be
- * specified.  Specifying a fixed address is not required on ppc64, i386
- * or x86_64.
+ * For the ia64 architecture, the Linux kernel reserves Region number 4 for
+ * huge pages.  That means that if one requires a fixed address, a huge page
+ * aligned address starting with 0x800000... will be required.  If a fixed
+ * address is not required, the kernel will select an address in the proper
+ * range.
+ * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
  */
 #include <stdlib.h>
 #include <stdio.h>
@@ -317,14 +410,8 @@ int main(void)
 #define LENGTH (256UL*1024*1024)
 #define PROTECTION (PROT_READ | PROT_WRITE)
 
-/* Only ia64 requires this */
-#ifdef __ia64__
-#define ADDR (void *)(0x8000000000000000UL)
-#define FLAGS (MAP_SHARED | MAP_FIXED)
-#else
-#define ADDR (void *)(0x0UL)
+#define ADDR (void *)(0x0UL)	/* let kernel choose address */
 #define FLAGS (MAP_SHARED)
-#endif
 
 void check_bytes(char *addr)
 {

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from
	task mempolicy
Date: Tue, 1 Sep 2009 15:47:19 +0100
Message-ID: <20090901144719.GA7548@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Fri, Aug 28, 2009 at 12:03:32PM -0400, Lee Schermerhorn wrote:
> [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from task mempolicy
> 
> Against: 2.6.31-rc7-mmotm-090827-0057
> 
> V2:
> + cleaned up comments, removed some deemed unnecessary,
>   add some suggested by review
> + removed check for !current in huge_mpol_nodes_allowed().
> + added 'current->comm' to warning message in huge_mpol_nodes_allowed().
> + added VM_BUG_ON() assertion in hugetlb.c next_node_allowed() to
>   catch out of range node id.
> + add examples to patch description
> 
> V3: Factored this patch from V2 patch 2/3
> 
> V4: added back missing "kfree(nodes_allowed)" in set_max_nr_hugepages()
> 
> V5: remove internal '\n' from printk in huge_mpol_nodes_allowed()
> 
> This patch derives a "nodes_allowed" node mask from the numa
> mempolicy of the task modifying the number of persistent huge
> pages to control the allocation, freeing and adjusting of surplus
> huge pages.  This mask is derived as follows:
> 
> * For "default" [NULL] task mempolicy, a NULL nodemask_t pointer
>   is produced.  This will cause the hugetlb subsystem to use
>   node_online_map as the "nodes_allowed".  This preserves the
>   behavior before this patch.
> * For "preferred" mempolicy, including explicit local allocation,
>   a nodemask with the single preferred node will be produced. 
>   "local" policy will NOT track any internode migrations of the
>   task adjusting nr_hugepages.
> * For "bind" and "interleave" policy, the mempolicy's nodemask
>   will be used.
> * Other than to inform the construction of the nodes_allowed node
>   mask, the actual mempolicy mode is ignored.  That is, all modes
>   behave like interleave over the resulting nodes_allowed mask
>   with no "fallback".
> 
> Notes:
> 
> 1) This patch introduces a subtle change in behavior:  huge page
>    allocation and freeing will be constrained by any mempolicy
>    that the task adjusting the huge page pool inherits from its
>    parent.  This policy could come from a distant ancestor.  The
>    adminstrator adjusting the huge page pool without explicitly
>    specifying a mempolicy via numactl might be surprised by this.
>    Additionaly, any mempolicy specified by numactl will be
>    constrained by the cpuset in which numactl is invoked.
>    Using sysfs per node hugepages attributes to adjust the per
>    node persistent huge pages count [subsequent patch] ignores
>    mempolicy and cpuset constraints.
> 
> 2) Hugepages allocated at boot time use the node_online_map.
>    An additional patch could implement a temporary boot time
>    huge pages nodes_allowed command line parameter.
> 
> 3) Using mempolicy to control persistent huge page allocation
>    and freeing requires no change to hugeadm when invoking
>    it via numactl, as shown in the examples below.  However,
>    hugeadm could be enhanced to take the allowed nodes as an
>    argument and set its task mempolicy itself.  This would allow
>    it to detect and warn about any non-default mempolicy that it
>    inherited from its parent, thus alleviating the issue described
>    in Note 1 above.
> 
> See the updated documentation [next patch] for more information
> about the implications of this patch.
> 
> Examples:
> 
> Starting with:
> 
> 	Node 0 HugePages_Total:     0
> 	Node 1 HugePages_Total:     0
> 	Node 2 HugePages_Total:     0
> 	Node 3 HugePages_Total:     0
> 
> Default behavior [with or without this patch] balances persistent
> hugepage allocation across nodes [with sufficient contiguous memory]:
> 
> 	hugeadm --pool-pages-min=2048Kb:32
> 
> yields:
> 
> 	Node 0 HugePages_Total:     8
> 	Node 1 HugePages_Total:     8
> 	Node 2 HugePages_Total:     8
> 	Node 3 HugePages_Total:     8
> 
> Applying mempolicy--e.g., with numactl [using '-m' a.k.a.
> '--membind' because it allows multiple nodes to be specified
> and it's easy to type]--we can allocate huge pages on
> individual nodes or sets of nodes.  So, starting from the 
> condition above, with 8 huge pages per node:
> 
> 	numactl -m 2 hugeadm --pool-pages-min=2048Kb:+8
> 
> yields:
> 
> 	Node 0 HugePages_Total:     8
> 	Node 1 HugePages_Total:     8
> 	Node 2 HugePages_Total:    16
> 	Node 3 HugePages_Total:     8
> 
> The incremental 8 huge pages were restricted to node 2 by the
> specified mempolicy.
> 
> Similarly, we can use mempolicy to free persistent huge pages
> from specified nodes:
> 
> 	numactl -m 0,1 hugeadm --pool-pages-min=2048Kb:-8
> 
> yields:
> 
> 	Node 0 HugePages_Total:     4
> 	Node 1 HugePages_Total:     4
> 	Node 2 HugePages_Total:    16
> 	Node 3 HugePages_Total:     8
> 
> The 8 huge pages freed were balanced over nodes 0 and 1.
> 
> Acked-by: Mel Gorman <mel@csn.ul.ie>
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 

This seems to behave as advertised and I could spot no other problems in
the code so make that a;

Reviewed-by: Mel Gorman <mel@csn.ul.ie>

As an aside, I think the ordering of the signed-offs, acks and reviews
are in the wrong order. The ordering of the lines is the order people
were involved in. You are the first as the author and I'm the second so
it should be

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
Reviewed-by: Mel Gorman <mel@csn.ul.ie>

rather than the other way around.

>  include/linux/mempolicy.h |    3 ++
>  mm/hugetlb.c              |   14 ++++++----
>  mm/mempolicy.c            |   61 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 73 insertions(+), 5 deletions(-)
> 
> 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.
> + */
> +nodemask_t *huge_mpol_nodes_allowed(void)
> +{
> +	nodemask_t *nodes_allowed = NULL;
> +	struct mempolicy *mempolicy;
> +	int nid;
> +
> +	if (!current->mempolicy)
> +		return NULL;
> +
> +	mpol_get(current->mempolicy);
> +	nodes_allowed = kmalloc(sizeof(*nodes_allowed), GFP_KERNEL);
> +	if (!nodes_allowed) {
> +		printk(KERN_WARNING "%s unable to allocate nodes allowed mask "
> +			"for huge page allocation.  Falling back to default.\n",
> +			current->comm);
> +		goto out;
> +	}
> +	nodes_clear(*nodes_allowed);
> +
> +	mempolicy = current->mempolicy;
> +	switch (mempolicy->mode) {
> +	case MPOL_PREFERRED:
> +		if (mempolicy->flags & MPOL_F_LOCAL)
> +			nid = numa_node_id();
> +		else
> +			nid = mempolicy->v.preferred_node;
> +		node_set(nid, *nodes_allowed);
> +		break;
> +
> +	case MPOL_BIND:
> +		/* Fall through */
> +	case MPOL_INTERLEAVE:
> +		*nodes_allowed =  mempolicy->v.nodes;
> +		break;
> +
> +	default:
> +		BUG();
> +	}
> +
> +out:
> +	mpol_put(current->mempolicy);
> +	return nodes_allowed;
> +}
>  #endif
>  
>  /* Allocate a page in interleaved policy.
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/mempolicy.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/mempolicy.h	2009-08-28 09:21:20.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/mempolicy.h	2009-08-28 09:21:28.000000000 -0400
> @@ -201,6 +201,7 @@ extern void mpol_fix_fork_child_flag(str
>  extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
>  				unsigned long addr, gfp_t gfp_flags,
>  				struct mempolicy **mpol, nodemask_t **nodemask);
> +extern nodemask_t *huge_mpol_nodes_allowed(void);
>  extern unsigned slab_node(struct mempolicy *policy);
>  
>  extern enum zone_type policy_zone;
> @@ -328,6 +329,8 @@ static inline struct zonelist *huge_zone
>  	return node_zonelist(0, gfp_flags);
>  }
>  
> +static inline nodemask_t *huge_mpol_nodes_allowed(void) { return NULL; }
> +
>  static inline int do_migrate_pages(struct mm_struct *mm,
>  			const nodemask_t *from_nodes,
>  			const nodemask_t *to_nodes, int flags)
> Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:26.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
> @@ -1248,10 +1248,13 @@ static int adjust_pool_surplus(struct hs
>  static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
>  {
>  	unsigned long min_count, ret;
> +	nodemask_t *nodes_allowed;
>  
>  	if (h->order >= MAX_ORDER)
>  		return h->max_huge_pages;
>  
> +	nodes_allowed = huge_mpol_nodes_allowed();
> +
>  	/*
>  	 * Increase the pool size
>  	 * First take pages out of surplus state.  Then make up the
> @@ -1265,7 +1268,7 @@ static unsigned long set_max_huge_pages(
>  	 */
>  	spin_lock(&hugetlb_lock);
>  	while (h->surplus_huge_pages && count > persistent_huge_pages(h)) {
> -		if (!adjust_pool_surplus(h, NULL, -1))
> +		if (!adjust_pool_surplus(h, nodes_allowed, -1))
>  			break;
>  	}
>  
> @@ -1276,7 +1279,7 @@ static unsigned long set_max_huge_pages(
>  		 * and reducing the surplus.
>  		 */
>  		spin_unlock(&hugetlb_lock);
> -		ret = alloc_fresh_huge_page(h, NULL);
> +		ret = alloc_fresh_huge_page(h, nodes_allowed);
>  		spin_lock(&hugetlb_lock);
>  		if (!ret)
>  			goto out;
> @@ -1300,18 +1303,19 @@ static unsigned long set_max_huge_pages(
>  	 */
>  	min_count = h->resv_huge_pages + h->nr_huge_pages - h->free_huge_pages;
>  	min_count = max(count, min_count);
> -	try_to_free_low(h, min_count, NULL);
> +	try_to_free_low(h, min_count, nodes_allowed);
>  	while (min_count < persistent_huge_pages(h)) {
> -		if (!free_pool_huge_page(h, NULL, 0))
> +		if (!free_pool_huge_page(h, nodes_allowed, 0))
>  			break;
>  	}
>  	while (count < persistent_huge_pages(h)) {
> -		if (!adjust_pool_surplus(h, NULL, 1))
> +		if (!adjust_pool_surplus(h, nodes_allowed, 1))
>  			break;
>  	}
>  out:
>  	ret = persistent_huge_pages(h);
>  	spin_unlock(&hugetlb_lock);
> +	kfree(nodes_allowed);
>  	return ret;
>  }
>  
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
Date: Tue, 1 Sep 2009 15:49:32 +0100
Message-ID: <20090901144932.GB7548@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160338.11080.51282.sendpatchset@localhost.localdomain>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20090828160338.11080.51282.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Fri, Aug 28, 2009 at 12:03:38PM -0400, Lee Schermerhorn wrote:
> [PATCH 4/6] - hugetlb:  introduce alloc_nodemask_of_node()
> 
> Against:  2.6.31-rc7-mmotm-090827-0057
> 
> New in V5 of series
> 
> Introduce nodemask macro to allocate a nodemask and 
> initialize it to contain a single node, using the macro
> init_nodemask_of_node() factored out of the nodemask_of_node()
> macro.
> 
> alloc_nodemask_of_node() coded as a macro to avoid header
> dependency hell.
> 
> This will be used to construct the huge pages "nodes_allowed"
> nodemask for a single node when a persistent huge page
> pool page count is modified via a per node sysfs attribute.
> 
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 
>  include/linux/nodemask.h |   20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h	2009-08-28 09:21:19.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h	2009-08-28 09:21:29.000000000 -0400
> @@ -245,18 +245,34 @@ static inline int __next_node(int n, con
>  	return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
>  }
>  
> +#define init_nodemask_of_nodes(mask, node)				\
> +	nodes_clear(*(mask));						\
> +	node_set((node), *(mask));
> +

Is the done thing to either make this a static inline or else wrap it in
a do { } while(0) ? The reasoning being that if this is used as part of an
another statement (e.g. a for loop) that it'll actually compile instead of
throw up weird error messages.

>  #define nodemask_of_node(node)						\
>  ({									\
>  	typeof(_unused_nodemask_arg_) m;				\
>  	if (sizeof(m) == sizeof(unsigned long)) {			\
>  		m.bits[0] = 1UL<<(node);				\
>  	} else {							\
> -		nodes_clear(m);						\
> -		node_set((node), m);					\
> +		init_nodemask_of_nodes(&m, (node));			\
>  	}								\
>  	m;								\
>  })
>  
> +/*
> + * returns pointer to kmalloc()'d nodemask initialized to contain the
> + * specified node.  Caller must free with kfree().
> + */
> +#define alloc_nodemask_of_node(node)					\
> +({									\
> +	typeof(_unused_nodemask_arg_) *nmp;				\
> +	nmp = kmalloc(sizeof(*nmp), GFP_KERNEL);			\
> +	if (nmp)							\
> +		init_nodemask_of_nodes(nmp, (node));			\
> +	nmp;								\
> +})
> +

Otherwise, it looks ok.

>  #define first_unset_node(mask) __first_unset_node(&(mask))
>  static inline int __first_unset_node(const nodemask_t *maskp)
>  {
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
Date: Tue, 1 Sep 2009 16:20:15 +0100
Message-ID: <20090901152015.GC7548@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Fri, Aug 28, 2009 at 12:03:44PM -0400, Lee Schermerhorn wrote:
> [PATCH 5/6] hugetlb:  register per node hugepages attributes
> 
> Against: 2.6.31-rc7-mmotm-090820-1918
> 
> V2:  remove dependency on kobject private bitfield.  Search
>      global hstates then all per node hstates for kobject
>      match in attribute show/store functions.
> 
> V3:  rebase atop the mempolicy-based hugepage alloc/free;
>      use custom "nodes_allowed" to restrict alloc/free to
>      a specific node via per node attributes.  Per node
>      attribute overrides mempolicy.  I.e., mempolicy only
>      applies to global attributes.
> 
> V5:  Fix issues raised by Mel Gorman:
>      + add !NUMA versions of hugetlb_[un]register_node()
>      + rename 'hi' to 'i' in kobj_to_node_hstate()
>      + rename (count, input) to (len, count) in nr_hugepages_store()
>      + moved per node hugepages_kobj and hstate_kobjs[] from the
>        struct node [sysdev] to hugetlb.c private arrays.
>      + changed registration mechanism so that hugetlbfs [a module]
>        register its attributes registration callbacks with the node
>        driver, eliminating the dependency between the node driver
>        and hugetlbfs.  From it's init func, hugetlbfs will register
>        all on-line nodes' hugepage sysfs attributes along with
>        hugetlbfs' attributes register/unregister functions.  The
>        node driver will use these functions to [un]register nodes
>        with hugetlbfs on node hot-plug.
>      + replaced hugetlb.c private "nodes_allowed_from_node()" with
>        [new] generic "alloc_nodemask_of_node()".
> 
> V5a: + fix !NUMA register_hugetlbfs_with_node():  don't use
>        keyword 'do' as parameter name!
> 
> This patch adds the per huge page size control/query attributes
> to the per node sysdevs:
> 
> /sys/devices/system/node/node<ID>/hugepages/hugepages-<size>/
> 	nr_hugepages       - r/w
> 	free_huge_pages    - r/o
> 	surplus_huge_pages - r/o
> 
> The patch attempts to re-use/share as much of the existing
> global hstate attribute initialization and handling, and the
> "nodes_allowed" constraint processing as possible.
> Calling set_max_huge_pages() with no node indicates a change to
> global hstate parameters.  In this case, any non-default task
> mempolicy will be used to generate the nodes_allowed mask.  A
> valid node id indicates an update to that node's hstate 
> parameters, and the count argument specifies the target count
> for the specified node.  From this info, we compute the target
> global count for the hstate and construct a nodes_allowed node
> mask contain only the specified node.
> 
> Setting the node specific nr_hugepages via the per node attribute
> effectively ignores any task mempolicy or cpuset constraints.
> 
> With this patch:
> 
> (me):ls /sys/devices/system/node/node0/hugepages/hugepages-2048kB
> ./  ../  free_hugepages  nr_hugepages  surplus_hugepages
> 
> Starting from:
> Node 0 HugePages_Total:     0
> Node 0 HugePages_Free:      0
> Node 0 HugePages_Surp:      0
> Node 1 HugePages_Total:     0
> Node 1 HugePages_Free:      0
> Node 1 HugePages_Surp:      0
> Node 2 HugePages_Total:     0
> Node 2 HugePages_Free:      0
> Node 2 HugePages_Surp:      0
> Node 3 HugePages_Total:     0
> Node 3 HugePages_Free:      0
> Node 3 HugePages_Surp:      0
> vm.nr_hugepages = 0
> 
> Allocate 16 persistent huge pages on node 2:
> (me):echo 16 >/sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages
> 
> [Note that this is equivalent to:
> 	numactl -m 2 hugeadmin --pool-pages-min 2M:+16
> ]
> 
> Yields:
> Node 0 HugePages_Total:     0
> Node 0 HugePages_Free:      0
> Node 0 HugePages_Surp:      0
> Node 1 HugePages_Total:     0
> Node 1 HugePages_Free:      0
> Node 1 HugePages_Surp:      0
> Node 2 HugePages_Total:    16
> Node 2 HugePages_Free:     16
> Node 2 HugePages_Surp:      0
> Node 3 HugePages_Total:     0
> Node 3 HugePages_Free:      0
> Node 3 HugePages_Surp:      0
> vm.nr_hugepages = 16
> 
> Global controls work as expected--reduce pool to 8 persistent huge pages:
> (me):echo 8 >/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
> 
> Node 0 HugePages_Total:     0
> Node 0 HugePages_Free:      0
> Node 0 HugePages_Surp:      0
> Node 1 HugePages_Total:     0
> Node 1 HugePages_Free:      0
> Node 1 HugePages_Surp:      0
> Node 2 HugePages_Total:     8
> Node 2 HugePages_Free:      8
> Node 2 HugePages_Surp:      0
> Node 3 HugePages_Total:     0
> Node 3 HugePages_Free:      0
> Node 3 HugePages_Surp:      0
> 
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 

Ok, this appears to be acting as advertised as well. It also builds and
boots on !NUMA which is something it tripped over before. The dependencies
between base NUMA support and hugetlbfs are still looking reasonable to my
eye and you've cleaned up the magic numbers I was whinging about the last time.

Basically I have no problem with it even though I still think that
memory policies were sufficient. I'm going to chicken out and leave it
up to David Rientjes but from me

Acked-by: Mel Gorman <mel@csn.ul.ie>

>  drivers/base/node.c  |   33 ++++++
>  include/linux/node.h |    8 +
>  include/linux/numa.h |    2 
>  mm/hugetlb.c         |  245 ++++++++++++++++++++++++++++++++++++++++++++-------
>  4 files changed, 258 insertions(+), 30 deletions(-)
> 
> Index: linux-2.6.31-rc7-mmotm-090827-0057/drivers/base/node.c
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/drivers/base/node.c	2009-08-28 09:21:17.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/drivers/base/node.c	2009-08-28 09:21:31.000000000 -0400
> @@ -177,6 +177,37 @@ static ssize_t node_read_distance(struct
>  }
>  static SYSDEV_ATTR(distance, S_IRUGO, node_read_distance, NULL);
>  
> +/*
> + * hugetlbfs per node attributes registration interface:
> + * When/if hugetlb[fs] subsystem initializes [sometime after this module],
> + * it will register it's per node attributes for all nodes on-line at that
> + * point.  It will also call register_hugetlbfs_with_node(), below, to
> + * register it's attribute registration functions with this node driver.
> + * Once these hooks have been initialized, the node driver will call into
> + * the hugetlb module to [un]register attributes for hot-plugged nodes.
> + */
> +NODE_REGISTRATION_FUNC __hugetlb_register_node;
> +NODE_REGISTRATION_FUNC __hugetlb_unregister_node;
> +
> +static inline void hugetlb_register_node(struct node *node)
> +{
> +	if (__hugetlb_register_node)
> +		__hugetlb_register_node(node);
> +}
> +
> +static inline void hugetlb_unregister_node(struct node *node)
> +{
> +	if (__hugetlb_unregister_node)
> +		__hugetlb_unregister_node(node);
> +}
> +
> +void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC doregister,
> +                                  NODE_REGISTRATION_FUNC unregister)
> +{
> +	__hugetlb_register_node   = doregister;
> +	__hugetlb_unregister_node = unregister;
> +}
> +
>  
>  /*
>   * register_node - Setup a sysfs device for a node.
> @@ -200,6 +231,7 @@ int register_node(struct node *node, int
>  		sysdev_create_file(&node->sysdev, &attr_distance);
>  
>  		scan_unevictable_register_node(node);
> +		hugetlb_register_node(node);
>  	}
>  	return error;
>  }
> @@ -220,6 +252,7 @@ void unregister_node(struct node *node)
>  	sysdev_remove_file(&node->sysdev, &attr_distance);
>  
>  	scan_unevictable_unregister_node(node);
> +	hugetlb_unregister_node(node);
>  
>  	sysdev_unregister(&node->sysdev);
>  }
> Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:31.000000000 -0400
> @@ -24,6 +24,7 @@
>  #include <asm/io.h>
>  
>  #include <linux/hugetlb.h>
> +#include <linux/node.h>
>  #include "internal.h"
>  
>  const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
> @@ -1245,7 +1246,8 @@ static int adjust_pool_surplus(struct hs
>  }
>  
>  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> -static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
> +static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> +								int nid)
>  {
>  	unsigned long min_count, ret;
>  	nodemask_t *nodes_allowed;
> @@ -1253,7 +1255,21 @@ static unsigned long set_max_huge_pages(
>  	if (h->order >= MAX_ORDER)
>  		return h->max_huge_pages;
>  
> -	nodes_allowed = huge_mpol_nodes_allowed();
> +	if (nid == NO_NODEID_SPECIFIED)
> +		nodes_allowed = huge_mpol_nodes_allowed();
> +	else {
> +		/*
> +		 * incoming 'count' is for node 'nid' only, so
> +		 * adjust count to global, but restrict alloc/free
> +		 * to the specified node.
> +		 */
> +		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
> +		nodes_allowed = alloc_nodemask_of_node(nid);
> +		if (!nodes_allowed)
> +			printk(KERN_WARNING "%s unable to allocate allowed "
> +			       "nodes mask for huge page allocation/free.  "
> +			       "Falling back to default.\n", current->comm);
> +	}
>  
>  	/*
>  	 * Increase the pool size
> @@ -1329,51 +1345,71 @@ out:
>  static struct kobject *hugepages_kobj;
>  static struct kobject *hstate_kobjs[HUGE_MAX_HSTATE];
>  
> -static struct hstate *kobj_to_hstate(struct kobject *kobj)
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp);
> +
> +static struct hstate *kobj_to_hstate(struct kobject *kobj, int *nidp)
>  {
>  	int i;
> +
>  	for (i = 0; i < HUGE_MAX_HSTATE; i++)
> -		if (hstate_kobjs[i] == kobj)
> +		if (hstate_kobjs[i] == kobj) {
> +			if (nidp)
> +				*nidp = NO_NODEID_SPECIFIED;
>  			return &hstates[i];
> -	BUG();
> -	return NULL;
> +		}
> +
> +	return kobj_to_node_hstate(kobj, nidp);
>  }
>  
>  static ssize_t nr_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->nr_huge_pages);
> +	struct hstate *h;
> +	unsigned long nr_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		nr_huge_pages = h->nr_huge_pages;
> +	else
> +		nr_huge_pages = h->nr_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", nr_huge_pages);
>  }
> +
>  static ssize_t nr_hugepages_store(struct kobject *kobj,
> -		struct kobj_attribute *attr, const char *buf, size_t count)
> +		struct kobj_attribute *attr, const char *buf, size_t len)
>  {
> +	unsigned long count;
> +	struct hstate *h;
> +	int nid;
>  	int err;
> -	unsigned long input;
> -	struct hstate *h = kobj_to_hstate(kobj);
>  
> -	err = strict_strtoul(buf, 10, &input);
> +	err = strict_strtoul(buf, 10, &count);
>  	if (err)
>  		return 0;
>  
> -	h->max_huge_pages = set_max_huge_pages(h, input);
> +	h = kobj_to_hstate(kobj, &nid);
> +	h->max_huge_pages = set_max_huge_pages(h, count, nid);
>  
> -	return count;
> +	return len;
>  }
>  HSTATE_ATTR(nr_hugepages);
>  
>  static ssize_t nr_overcommit_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> +
>  	return sprintf(buf, "%lu\n", h->nr_overcommit_huge_pages);
>  }
> +
>  static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
>  		struct kobj_attribute *attr, const char *buf, size_t count)
>  {
>  	int err;
>  	unsigned long input;
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
>  
>  	err = strict_strtoul(buf, 10, &input);
>  	if (err)
> @@ -1390,15 +1426,24 @@ HSTATE_ATTR(nr_overcommit_hugepages);
>  static ssize_t free_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->free_huge_pages);
> +	struct hstate *h;
> +	unsigned long free_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		free_huge_pages = h->free_huge_pages;
> +	else
> +		free_huge_pages = h->free_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", free_huge_pages);
>  }
>  HSTATE_ATTR_RO(free_hugepages);
>  
>  static ssize_t resv_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
>  	return sprintf(buf, "%lu\n", h->resv_huge_pages);
>  }
>  HSTATE_ATTR_RO(resv_hugepages);
> @@ -1406,8 +1451,17 @@ HSTATE_ATTR_RO(resv_hugepages);
>  static ssize_t surplus_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->surplus_huge_pages);
> +	struct hstate *h;
> +	unsigned long surplus_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		surplus_huge_pages = h->surplus_huge_pages;
> +	else
> +		surplus_huge_pages = h->surplus_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", surplus_huge_pages);
>  }
>  HSTATE_ATTR_RO(surplus_hugepages);
>  
> @@ -1424,19 +1478,21 @@ static struct attribute_group hstate_att
>  	.attrs = hstate_attrs,
>  };
>  
> -static int __init hugetlb_sysfs_add_hstate(struct hstate *h)
> +static int __init hugetlb_sysfs_add_hstate(struct hstate *h,
> +				struct kobject *parent,
> +				struct kobject **hstate_kobjs,
> +				struct attribute_group *hstate_attr_group)
>  {
>  	int retval;
> +	int hi = h - hstates;
>  
> -	hstate_kobjs[h - hstates] = kobject_create_and_add(h->name,
> -							hugepages_kobj);
> -	if (!hstate_kobjs[h - hstates])
> +	hstate_kobjs[hi] = kobject_create_and_add(h->name, parent);
> +	if (!hstate_kobjs[hi])
>  		return -ENOMEM;
>  
> -	retval = sysfs_create_group(hstate_kobjs[h - hstates],
> -							&hstate_attr_group);
> +	retval = sysfs_create_group(hstate_kobjs[hi], hstate_attr_group);
>  	if (retval)
> -		kobject_put(hstate_kobjs[h - hstates]);
> +		kobject_put(hstate_kobjs[hi]);
>  
>  	return retval;
>  }
> @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
>  		return;
>  
>  	for_each_hstate(h) {
> -		err = hugetlb_sysfs_add_hstate(h);
> +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> +					 hstate_kobjs, &hstate_attr_group);
>  		if (err)
>  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
>  								h->name);
>  	}
>  }
>  
> +#ifdef CONFIG_NUMA
> +
> +struct node_hstate {
> +	struct kobject		*hugepages_kobj;
> +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> +};
> +struct node_hstate node_hstates[MAX_NUMNODES];
> +
> +static struct attribute *per_node_hstate_attrs[] = {
> +	&nr_hugepages_attr.attr,
> +	&free_hugepages_attr.attr,
> +	&surplus_hugepages_attr.attr,
> +	NULL,
> +};
> +
> +static struct attribute_group per_node_hstate_attr_group = {
> +	.attrs = per_node_hstate_attrs,
> +};
> +
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++) {
> +		struct node_hstate *nhs = &node_hstates[nid];
> +		int i;
> +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> +			if (nhs->hstate_kobjs[i] == kobj) {
> +				if (nidp)
> +					*nidp = nid;
> +				return &hstates[i];
> +			}
> +	}
> +
> +	BUG();
> +	return NULL;
> +}
> +
> +void hugetlb_unregister_node(struct node *node)
> +{
> +	struct hstate *h;
> +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> +
> +	if (!nhs->hugepages_kobj)
> +		return;
> +
> +	for_each_hstate(h)
> +		if (nhs->hstate_kobjs[h - hstates]) {
> +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> +			nhs->hstate_kobjs[h - hstates] = NULL;
> +		}
> +
> +	kobject_put(nhs->hugepages_kobj);
> +	nhs->hugepages_kobj = NULL;
> +}
> +
> +static void hugetlb_unregister_all_nodes(void)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++)
> +		hugetlb_unregister_node(&node_devices[nid]);
> +
> +	register_hugetlbfs_with_node(NULL, NULL);
> +}
> +
> +void hugetlb_register_node(struct node *node)
> +{
> +	struct hstate *h;
> +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> +	int err;
> +
> +	if (nhs->hugepages_kobj)
> +		return;		/* already allocated */
> +
> +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> +							&node->sysdev.kobj);
> +	if (!nhs->hugepages_kobj)
> +		return;
> +
> +	for_each_hstate(h) {
> +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> +						nhs->hstate_kobjs,
> +						&per_node_hstate_attr_group);
> +		if (err) {
> +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> +					" for node %d\n",
> +						h->name, node->sysdev.id);
> +			hugetlb_unregister_node(node);
> +			break;
> +		}
> +	}
> +}
> +
> +static void hugetlb_register_all_nodes(void)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++) {
> +		struct node *node = &node_devices[nid];
> +		if (node->sysdev.id == nid)
> +			hugetlb_register_node(node);
> +	}
> +
> +	register_hugetlbfs_with_node(hugetlb_register_node,
> +                                     hugetlb_unregister_node);
> +}
> +#else	/* !CONFIG_NUMA */
> +
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> +{
> +	BUG();
> +	if (nidp)
> +		*nidp = -1;
> +	return NULL;
> +}
> +
> +static void hugetlb_unregister_all_nodes(void) { }
> +
> +static void hugetlb_register_all_nodes(void) { }
> +
> +#endif
> +
>  static void __exit hugetlb_exit(void)
>  {
>  	struct hstate *h;
>  
> +	hugetlb_unregister_all_nodes();
> +
>  	for_each_hstate(h) {
>  		kobject_put(hstate_kobjs[h - hstates]);
>  	}
> @@ -1496,6 +1678,8 @@ static int __init hugetlb_init(void)
>  
>  	hugetlb_sysfs_init();
>  
> +	hugetlb_register_all_nodes();
> +
>  	return 0;
>  }
>  module_init(hugetlb_init);
> @@ -1598,7 +1782,8 @@ int hugetlb_sysctl_handler(struct ctl_ta
>  	proc_doulongvec_minmax(table, write, buffer, length, ppos);
>  
>  	if (write)
> -		h->max_huge_pages = set_max_huge_pages(h, tmp);
> +		h->max_huge_pages = set_max_huge_pages(h, tmp,
> +		                                       NO_NODEID_SPECIFIED);
>  
>  	return 0;
>  }
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
> @@ -10,4 +10,6 @@
>  
>  #define MAX_NUMNODES    (1 << NODES_SHIFT)
>  
> +#define NO_NODEID_SPECIFIED	(-1)
> +
>  #endif /* _LINUX_NUMA_H */
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/node.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/node.h	2009-08-28 09:21:17.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/node.h	2009-08-28 09:21:31.000000000 -0400
> @@ -28,6 +28,7 @@ struct node {
>  
>  struct memory_block;
>  extern struct node node_devices[];
> +typedef  void (*NODE_REGISTRATION_FUNC)(struct node *);
>  
>  extern int register_node(struct node *, int, struct node *);
>  extern void unregister_node(struct node *node);
> @@ -39,6 +40,8 @@ extern int unregister_cpu_under_node(uns
>  extern int register_mem_sect_under_node(struct memory_block *mem_blk,
>  						int nid);
>  extern int unregister_mem_sect_under_nodes(struct memory_block *mem_blk);
> +extern void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC doregister,
> +                                         NODE_REGISTRATION_FUNC unregister);
>  #else
>  static inline int register_one_node(int nid)
>  {
> @@ -65,6 +68,11 @@ static inline int unregister_mem_sect_un
>  {
>  	return 0;
>  }
> +
> +static inline void register_hugetlbfs_with_node(NODE_REGISTRATION_FUNC reg,
> +                                                NODE_REGISTRATION_FUNC unreg)
> +{
> +}
>  #endif
>  
>  #define to_node(sys_device) container_of(sys_device, struct node, sysdev)
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
Date: Tue, 01 Sep 2009 12:42:14 -0400
Message-ID: <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160338.11080.51282.sendpatchset@localhost.localdomain>
	 <20090901144932.GB7548@csn.ul.ie>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <20090901144932.GB7548@csn.ul.ie>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Mel Gorman <mel@csn.ul.ie>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, David Rientjes <rientjes@google.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Tue, 2009-09-01 at 15:49 +0100, Mel Gorman wrote:
> On Fri, Aug 28, 2009 at 12:03:38PM -0400, Lee Schermerhorn wrote:
> > [PATCH 4/6] - hugetlb:  introduce alloc_nodemask_of_node()
> > 
> > Against:  2.6.31-rc7-mmotm-090827-0057
> > 
> > New in V5 of series
> > 
> > Introduce nodemask macro to allocate a nodemask and 
> > initialize it to contain a single node, using the macro
> > init_nodemask_of_node() factored out of the nodemask_of_node()
> > macro.
> > 
> > alloc_nodemask_of_node() coded as a macro to avoid header
> > dependency hell.
> > 
> > This will be used to construct the huge pages "nodes_allowed"
> > nodemask for a single node when a persistent huge page
> > pool page count is modified via a per node sysfs attribute.
> > 
> > Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> > 
> >  include/linux/nodemask.h |   20 ++++++++++++++++++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
> > ===================================================================
> > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h	2009-08-28 09:21:19.000000000 -0400
> > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h	2009-08-28 09:21:29.000000000 -0400
> > @@ -245,18 +245,34 @@ static inline int __next_node(int n, con
> >  	return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
> >  }
> >  
> > +#define init_nodemask_of_nodes(mask, node)				\
> > +	nodes_clear(*(mask));						\
> > +	node_set((node), *(mask));
> > +
> 
> Is the done thing to either make this a static inline or else wrap it in
> a do { } while(0) ? The reasoning being that if this is used as part of an
> another statement (e.g. a for loop) that it'll actually compile instead of
> throw up weird error messages.

Right.  I'll fix this [and signoff/review orders] next time [maybe last
time?].  It occurs to me that I can also use this for
huge_mpol_nodes_allowed(), so I'll move it up in the series and fix that
[which you've already ack'd].  I'll wait a bit to hear from David before
I respin.

Thanks,
Lee
> 
> >  #define nodemask_of_node(node)						\
> >  ({									\
> >  	typeof(_unused_nodemask_arg_) m;				\
> >  	if (sizeof(m) == sizeof(unsigned long)) {			\
> >  		m.bits[0] = 1UL<<(node);				\
> >  	} else {							\
> > -		nodes_clear(m);						\
> > -		node_set((node), m);					\
> > +		init_nodemask_of_nodes(&m, (node));			\
> >  	}								\
> >  	m;								\
> >  })
> >  
> > +/*
> > + * returns pointer to kmalloc()'d nodemask initialized to contain the
> > + * specified node.  Caller must free with kfree().
> > + */
> > +#define alloc_nodemask_of_node(node)					\
> > +({									\
> > +	typeof(_unused_nodemask_arg_) *nmp;				\
> > +	nmp = kmalloc(sizeof(*nmp), GFP_KERNEL);			\
> > +	if (nmp)							\
> > +		init_nodemask_of_nodes(nmp, (node));			\
> > +	nmp;								\
> > +})
> > +
> 
> Otherwise, it looks ok.
> 
> >  #define first_unset_node(mask) __first_unset_node(&(mask))
> >  static inline int __first_unset_node(const nodemask_t *maskp)
> >  {
> > 
> 


From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
Date: Thu, 3 Sep 2009 11:34:24 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909031122590.9055@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160338.11080.51282.sendpatchset@localhost.localdomain> <20090901144932.GB7548@csn.ul.ie> <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252002870; bh=cueyM18Wbr0NwTLVJX5qz3uheAg=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=SAYQ/UvJ/tnVUArudW+/2fL4U+IGryi
	9eeGgvwwHft+sZV1zwc+XgPF7UIKUsi9NZFg8FqFt75HJLD1L00AQWQ==
In-Reply-To: <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Tue, 1 Sep 2009, Lee Schermerhorn wrote:

> > > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
> > > ===================================================================
> > > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/nodemask.h	2009-08-28 09:21:19.000000000 -0400
> > > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h	2009-08-28 09:21:29.000000000 -0400
> > > @@ -245,18 +245,34 @@ static inline int __next_node(int n, con
> > >  	return min_t(int,MAX_NUMNODES,find_next_bit(srcp->bits, MAX_NUMNODES, n+1));
> > >  }
> > >  
> > > +#define init_nodemask_of_nodes(mask, node)				\
> > > +	nodes_clear(*(mask));						\
> > > +	node_set((node), *(mask));
> > > +
> > 
> > Is the done thing to either make this a static inline or else wrap it in
> > a do { } while(0) ? The reasoning being that if this is used as part of an
> > another statement (e.g. a for loop) that it'll actually compile instead of
> > throw up weird error messages.
> 
> Right.  I'll fix this [and signoff/review orders] next time [maybe last
> time?].  It occurs to me that I can also use this for
> huge_mpol_nodes_allowed(), so I'll move it up in the series and fix that
> [which you've already ack'd].  I'll wait a bit to hear from David before
> I respin.
> 

I think it should be an inline function just so there's typechecking on 
the first argument passed in (and so alloc_nodemask_of_node() below 
doesn't get a NULL pointer dereference on node_set() if nmp can't be 
allocated).

I've seen the issue about the signed-off-by/reviewed-by/acked-by order 
come up before.  I've always put my signed-off-by line last whenever 
proposing patches because it shows a clear order in who gathered those 
lines when submitting to -mm, for example.  If I write

	Cc: Mel Gorman <mel@csn.ul.ie>
	Signed-off-by: David Rientjes <rientjes@google.com>

it is clear that I cc'd Mel on the initial proposal.  If it is the other 
way around, for example,

	Signed-off-by: David Rientjes <rientjes@google.com>
	Cc: Mel Gorman <mel@csn.ul.ie>
	Signed-off-by: Andrew Morton...

then it indicates Andrew added the cc when merging into -mm.  That's more 
relevant when such a line is acked-by or reviewed-by since it is now 
possible to determine who received such acknowledgement from the 
individual and is responsible for correctly relaying it in the patch 
submission.

If it's done this way, it indicates that whoever is signing off the patch 
is responsible for everything above it.  The type of line (signed-off-by, 
reviewed-by, acked-by) is enough of an indication about the development 
history of the patch, I believe, and it doesn't require specific ordering 
to communicate (and the first line having to be a signed-off-by line isn't 
really important, it doesn't replace the From: line).

It also appears to be how both Linus merges his own patches with Cc's.

> > > +/*
> > > + * returns pointer to kmalloc()'d nodemask initialized to contain the
> > > + * specified node.  Caller must free with kfree().
> > > + */
> > > +#define alloc_nodemask_of_node(node)					\
> > > +({									\
> > > +	typeof(_unused_nodemask_arg_) *nmp;				\
> > > +	nmp = kmalloc(sizeof(*nmp), GFP_KERNEL);			\
> > > +	if (nmp)							\
> > > +		init_nodemask_of_nodes(nmp, (node));			\
> > > +	nmp;								\
> > > +})
> > > +
> > 

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 2/6] hugetlb:  add nodemask arg to huge page alloc, free
 and surplus adjust fcns
Date: Thu, 3 Sep 2009 11:39:39 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909031138010.9055@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160326.11080.56814.sendpatchset@localhost.localdomain>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252003187; bh=EO8ef4Ly1nati0d+4kcrgVcbeAM=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=dpMt7/l8Wjfuj+wLcWKGW4lFMbrgsKK
	klnFktd4RmheRGasb0adK0Hy+FhimDvqcn1oKuzg51NELVYdb4ThJWw==
In-Reply-To: <20090828160326.11080.56814.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Fri, 28 Aug 2009, Lee Schermerhorn wrote:

> [PATCH 2/6] hugetlb:  add nodemask arg to huge page alloc, free and surplus adjust fcns
> 
> Against:  2.6.31-rc7-mmotm-090827-0057
> 
> V3:
> + moved this patch to after the "rework" of hstate_next_node_to_...
>   functions as this patch is more specific to using task mempolicy
>   to control huge page allocation and freeing.
> 
> V5:
> + removed now unneeded 'nextnid' from hstate_next_node_to_{alloc|free}
>   and updated the stale comments.
> 
> In preparation for constraining huge page allocation and freeing by the
> controlling task's numa mempolicy, add a "nodes_allowed" nodemask pointer
> to the allocate, free and surplus adjustment functions.  For now, pass
> NULL to indicate default behavior--i.e., use node_online_map.  A
> subsqeuent patch will derive a non-default mask from the controlling 
> task's numa mempolicy.
> 
> Note that this method of updating the global hstate nr_hugepages under
> the constraint of a nodemask simplifies keeping the global state 
> consistent--especially the number of persistent and surplus pages
> relative to reservations and overcommit limits.  There are undoubtedly
> other ways to do this, but this works for both interfaces:  mempolicy
> and per node attributes.
> 
> Reviewed-by: Mel Gorman <mel@csn.ul.ie>
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

Still think the name `this_node_allowed()' is awkward, but I'm glad to see 
hstate_next_node_to_{alloc,free} is clean.

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

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from task
 mempolicy
Date: Thu, 3 Sep 2009 12:22:13 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909031212110.22173@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252005740; bh=EWO7zHkP4bLrd+rqLT4ypllZgXU=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=CCGpAMV3ZL+0ClpAkOpqqVgmedbcygA
	cPAMW7fTJ9yFd60Cnmq3dggHfVcI6g8WAbkfy1wjYKTSP3Qn9aKE01Q==
In-Reply-To: <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.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>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
Date: Thu, 3 Sep 2009 12:52:37 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252007565; bh=Q05g4bVXwrNAg+qbT1F7gLQnU6Q=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=nmupyQEiQcKF5HbnNnG6KqH+kH830X5
	Z3CxTH4N8ZB3c5Y35TWFGBxPMoZ/9lGpbhhln7MEmty1/7UbJNCk+Xw==
In-Reply-To: <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Fri, 28 Aug 2009, Lee Schermerhorn wrote:

> Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:31.000000000 -0400
> @@ -24,6 +24,7 @@
>  #include <asm/io.h>
>  
>  #include <linux/hugetlb.h>
> +#include <linux/node.h>
>  #include "internal.h"
>  
>  const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
> @@ -1245,7 +1246,8 @@ static int adjust_pool_surplus(struct hs
>  }
>  
>  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> -static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
> +static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> +								int nid)
>  {
>  	unsigned long min_count, ret;
>  	nodemask_t *nodes_allowed;
> @@ -1253,7 +1255,21 @@ static unsigned long set_max_huge_pages(
>  	if (h->order >= MAX_ORDER)
>  		return h->max_huge_pages;
>  
> -	nodes_allowed = huge_mpol_nodes_allowed();
> +	if (nid == NO_NODEID_SPECIFIED)
> +		nodes_allowed = huge_mpol_nodes_allowed();
> +	else {
> +		/*
> +		 * incoming 'count' is for node 'nid' only, so
> +		 * adjust count to global, but restrict alloc/free
> +		 * to the specified node.
> +		 */
> +		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
> +		nodes_allowed = alloc_nodemask_of_node(nid);
> +		if (!nodes_allowed)
> +			printk(KERN_WARNING "%s unable to allocate allowed "
> +			       "nodes mask for huge page allocation/free.  "
> +			       "Falling back to default.\n", current->comm);
> +	}
>  
>  	/*
>  	 * Increase the pool size
> @@ -1329,51 +1345,71 @@ out:
>  static struct kobject *hugepages_kobj;
>  static struct kobject *hstate_kobjs[HUGE_MAX_HSTATE];
>  
> -static struct hstate *kobj_to_hstate(struct kobject *kobj)
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp);
> +
> +static struct hstate *kobj_to_hstate(struct kobject *kobj, int *nidp)
>  {
>  	int i;
> +
>  	for (i = 0; i < HUGE_MAX_HSTATE; i++)
> -		if (hstate_kobjs[i] == kobj)
> +		if (hstate_kobjs[i] == kobj) {
> +			if (nidp)
> +				*nidp = NO_NODEID_SPECIFIED;
>  			return &hstates[i];
> -	BUG();
> -	return NULL;
> +		}
> +
> +	return kobj_to_node_hstate(kobj, nidp);
>  }
>  
>  static ssize_t nr_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->nr_huge_pages);
> +	struct hstate *h;
> +	unsigned long nr_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		nr_huge_pages = h->nr_huge_pages;
> +	else
> +		nr_huge_pages = h->nr_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", nr_huge_pages);
>  }
> +
>  static ssize_t nr_hugepages_store(struct kobject *kobj,
> -		struct kobj_attribute *attr, const char *buf, size_t count)
> +		struct kobj_attribute *attr, const char *buf, size_t len)
>  {
> +	unsigned long count;
> +	struct hstate *h;
> +	int nid;
>  	int err;
> -	unsigned long input;
> -	struct hstate *h = kobj_to_hstate(kobj);
>  
> -	err = strict_strtoul(buf, 10, &input);
> +	err = strict_strtoul(buf, 10, &count);
>  	if (err)
>  		return 0;
>  
> -	h->max_huge_pages = set_max_huge_pages(h, input);
> +	h = kobj_to_hstate(kobj, &nid);
> +	h->max_huge_pages = set_max_huge_pages(h, count, nid);
>  
> -	return count;
> +	return len;
>  }
>  HSTATE_ATTR(nr_hugepages);
>  
>  static ssize_t nr_overcommit_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> +
>  	return sprintf(buf, "%lu\n", h->nr_overcommit_huge_pages);
>  }
> +
>  static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
>  		struct kobj_attribute *attr, const char *buf, size_t count)
>  {
>  	int err;
>  	unsigned long input;
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
>  
>  	err = strict_strtoul(buf, 10, &input);
>  	if (err)
> @@ -1390,15 +1426,24 @@ HSTATE_ATTR(nr_overcommit_hugepages);
>  static ssize_t free_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->free_huge_pages);
> +	struct hstate *h;
> +	unsigned long free_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		free_huge_pages = h->free_huge_pages;
> +	else
> +		free_huge_pages = h->free_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", free_huge_pages);
>  }
>  HSTATE_ATTR_RO(free_hugepages);
>  
>  static ssize_t resv_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> +	struct hstate *h = kobj_to_hstate(kobj, NULL);
>  	return sprintf(buf, "%lu\n", h->resv_huge_pages);
>  }
>  HSTATE_ATTR_RO(resv_hugepages);
> @@ -1406,8 +1451,17 @@ HSTATE_ATTR_RO(resv_hugepages);
>  static ssize_t surplus_hugepages_show(struct kobject *kobj,
>  					struct kobj_attribute *attr, char *buf)
>  {
> -	struct hstate *h = kobj_to_hstate(kobj);
> -	return sprintf(buf, "%lu\n", h->surplus_huge_pages);
> +	struct hstate *h;
> +	unsigned long surplus_huge_pages;
> +	int nid;
> +
> +	h = kobj_to_hstate(kobj, &nid);
> +	if (nid == NO_NODEID_SPECIFIED)
> +		surplus_huge_pages = h->surplus_huge_pages;
> +	else
> +		surplus_huge_pages = h->surplus_huge_pages_node[nid];
> +
> +	return sprintf(buf, "%lu\n", surplus_huge_pages);
>  }
>  HSTATE_ATTR_RO(surplus_hugepages);
>  
> @@ -1424,19 +1478,21 @@ static struct attribute_group hstate_att
>  	.attrs = hstate_attrs,
>  };
>  
> -static int __init hugetlb_sysfs_add_hstate(struct hstate *h)
> +static int __init hugetlb_sysfs_add_hstate(struct hstate *h,
> +				struct kobject *parent,
> +				struct kobject **hstate_kobjs,
> +				struct attribute_group *hstate_attr_group)
>  {
>  	int retval;
> +	int hi = h - hstates;
>  
> -	hstate_kobjs[h - hstates] = kobject_create_and_add(h->name,
> -							hugepages_kobj);
> -	if (!hstate_kobjs[h - hstates])
> +	hstate_kobjs[hi] = kobject_create_and_add(h->name, parent);
> +	if (!hstate_kobjs[hi])
>  		return -ENOMEM;
>  
> -	retval = sysfs_create_group(hstate_kobjs[h - hstates],
> -							&hstate_attr_group);
> +	retval = sysfs_create_group(hstate_kobjs[hi], hstate_attr_group);
>  	if (retval)
> -		kobject_put(hstate_kobjs[h - hstates]);
> +		kobject_put(hstate_kobjs[hi]);
>  
>  	return retval;
>  }
> @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
>  		return;
>  
>  	for_each_hstate(h) {
> -		err = hugetlb_sysfs_add_hstate(h);
> +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> +					 hstate_kobjs, &hstate_attr_group);
>  		if (err)
>  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
>  								h->name);
>  	}
>  }
>  
> +#ifdef CONFIG_NUMA
> +
> +struct node_hstate {
> +	struct kobject		*hugepages_kobj;
> +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> +};
> +struct node_hstate node_hstates[MAX_NUMNODES];
> +
> +static struct attribute *per_node_hstate_attrs[] = {
> +	&nr_hugepages_attr.attr,
> +	&free_hugepages_attr.attr,
> +	&surplus_hugepages_attr.attr,
> +	NULL,
> +};
> +
> +static struct attribute_group per_node_hstate_attr_group = {
> +	.attrs = per_node_hstate_attrs,
> +};
> +
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++) {
> +		struct node_hstate *nhs = &node_hstates[nid];
> +		int i;
> +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> +			if (nhs->hstate_kobjs[i] == kobj) {
> +				if (nidp)
> +					*nidp = nid;
> +				return &hstates[i];
> +			}
> +	}
> +
> +	BUG();
> +	return NULL;
> +}
> +
> +void hugetlb_unregister_node(struct node *node)
> +{
> +	struct hstate *h;
> +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> +
> +	if (!nhs->hugepages_kobj)
> +		return;
> +
> +	for_each_hstate(h)
> +		if (nhs->hstate_kobjs[h - hstates]) {
> +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> +			nhs->hstate_kobjs[h - hstates] = NULL;
> +		}
> +
> +	kobject_put(nhs->hugepages_kobj);
> +	nhs->hugepages_kobj = NULL;
> +}
> +
> +static void hugetlb_unregister_all_nodes(void)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++)
> +		hugetlb_unregister_node(&node_devices[nid]);
> +
> +	register_hugetlbfs_with_node(NULL, NULL);
> +}
> +
> +void hugetlb_register_node(struct node *node)
> +{
> +	struct hstate *h;
> +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> +	int err;
> +
> +	if (nhs->hugepages_kobj)
> +		return;		/* already allocated */
> +
> +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> +							&node->sysdev.kobj);
> +	if (!nhs->hugepages_kobj)
> +		return;
> +
> +	for_each_hstate(h) {
> +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> +						nhs->hstate_kobjs,
> +						&per_node_hstate_attr_group);
> +		if (err) {
> +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> +					" for node %d\n",
> +						h->name, node->sysdev.id);

Maybe add `err' to the printk so we know whether it was an -ENOMEM 
condition or sysfs problem?

> +			hugetlb_unregister_node(node);
> +			break;
> +		}
> +	}
> +}
> +
> +static void hugetlb_register_all_nodes(void)
> +{
> +	int nid;
> +
> +	for (nid = 0; nid < nr_node_ids; nid++) {

Don't you want to do this for all nodes in N_HIGH_MEMORY?  I don't think 
we should be adding attributes for memoryless nodes.

> +		struct node *node = &node_devices[nid];
> +		if (node->sysdev.id == nid)
> +			hugetlb_register_node(node);
> +	}
> +
> +	register_hugetlbfs_with_node(hugetlb_register_node,
> +                                     hugetlb_unregister_node);
> +}
> +#else	/* !CONFIG_NUMA */
> +
> +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> +{
> +	BUG();
> +	if (nidp)
> +		*nidp = -1;
> +	return NULL;
> +}
> +
> +static void hugetlb_unregister_all_nodes(void) { }
> +
> +static void hugetlb_register_all_nodes(void) { }
> +
> +#endif
> +
>  static void __exit hugetlb_exit(void)
>  {
>  	struct hstate *h;
>  
> +	hugetlb_unregister_all_nodes();
> +
>  	for_each_hstate(h) {
>  		kobject_put(hstate_kobjs[h - hstates]);
>  	}
> @@ -1496,6 +1678,8 @@ static int __init hugetlb_init(void)
>  
>  	hugetlb_sysfs_init();
>  
> +	hugetlb_register_all_nodes();
> +
>  	return 0;
>  }
>  module_init(hugetlb_init);
> @@ -1598,7 +1782,8 @@ int hugetlb_sysctl_handler(struct ctl_ta
>  	proc_doulongvec_minmax(table, write, buffer, length, ppos);
>  
>  	if (write)
> -		h->max_huge_pages = set_max_huge_pages(h, tmp);
> +		h->max_huge_pages = set_max_huge_pages(h, tmp,
> +		                                       NO_NODEID_SPECIFIED);
>  
>  	return 0;
>  }
> Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
> @@ -10,4 +10,6 @@
>  
>  #define MAX_NUMNODES    (1 << NODES_SHIFT)
>  
> +#define NO_NODEID_SPECIFIED	(-1)
> +
>  #endif /* _LINUX_NUMA_H */

Hmm, so we already have NUMA_NO_NODE in the ia64 and x86_64 code and 
NID_INVAL in the ACPI code, both of which are defined to -1.  Maybe rename 
your addition here in favor of NUMA_NO_NODE, remove it from the ia64 and 
x86 arch headers, and convert the ACPI code?

Thanks for doing this!

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Thu, 3 Sep 2009 13:07:57 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252008485; bh=UhkvxZuDcldtMYAFVE8DFfrl3Hk=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=QIXx8W8Y3X43QmuBMOPGu4k2Q1/J1TI
	cEbr1BHfLZC8oNT8WGqkDCPMjI85SXMjl9TZeXEgRtaN8JkQBIYddDQ==
In-Reply-To: <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com, Randy Dunlap <randy.dunlap@oracle.com>

On Fri, 28 Aug 2009, Lee Schermerhorn wrote:

> [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy based management.
> 
> Against: 2.6.31-rc7-mmotm-090827-0057
> 
> V2:  Add brief description of per node attributes.
> 
> This patch updates the kernel huge tlb documentation to describe the
> numa memory policy based huge page management.  Additionaly, the patch
> includes a fair amount of rework to improve consistency, eliminate
> duplication and set the context for documenting the memory policy
> interaction.
> 
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

Adding Randy to the cc.  Comments below, but otherwise:

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

> 
>  Documentation/vm/hugetlbpage.txt |  257 ++++++++++++++++++++++++++-------------
>  1 file changed, 172 insertions(+), 85 deletions(-)
> 
> Index: linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt
> ===================================================================
> --- linux-2.6.31-rc7-mmotm-090827-0057.orig/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:16.000000000 -0400
> +++ linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:32.000000000 -0400
> @@ -11,23 +11,21 @@ This optimization is more critical now a
>  (several GBs) are more readily available.
>  
>  Users can use the huge page support in Linux kernel by either using the mmap
> -system call or standard SYSv shared memory system calls (shmget, shmat).
> +system call or standard SYSV shared memory system calls (shmget, shmat).
>  
>  First the Linux kernel needs to be built with the CONFIG_HUGETLBFS
>  (present under "File systems") and CONFIG_HUGETLB_PAGE (selected
>  automatically when CONFIG_HUGETLBFS is selected) configuration
>  options.
>  
> -The kernel built with huge page support should show the number of configured
> -huge pages in the system by running the "cat /proc/meminfo" command.
> +The /proc/meminfo file provides information about the total number of hugetlb
> +pages preallocated in the kernel's huge page pool.  It also displays
> +information about the number of free, reserved and surplus huge pages and the
> +[default] huge page size.  The huge page size is needed for generating the

Don't think the brackets are needed.

> +proper alignment and size of the arguments to system calls that map huge page
> +regions.
>  
> -/proc/meminfo also provides information about the total number of hugetlb
> -pages configured in the kernel.  It also displays information about the
> -number of free hugetlb pages at any time.  It also displays information about
> -the configured huge page size - this is needed for generating the proper
> -alignment and size of the arguments to the above system calls.
> -
> -The output of "cat /proc/meminfo" will have lines like:
> +The output of "cat /proc/meminfo" will include lines like:
>  
>  .....
>  HugePages_Total: vvv
> @@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
>  /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
>  in the kernel.
>  
> -/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
> -pages in the kernel.  Super user can dynamically request more (or free some
> -pre-configured) huge pages.
> -The allocation (or deallocation) of hugetlb pages is possible only if there are
> -enough physically contiguous free pages in system (freeing of huge pages is
> -possible only if there are enough hugetlb pages free that can be transferred
> -back to regular memory pool).
> -
> -Pages that are used as hugetlb pages are reserved inside the kernel and cannot
> -be used for other purposes.
> -
> -Once the kernel with Hugetlb page support is built and running, a user can
> -use either the mmap system call or shared memory system calls to start using
> -the huge pages.  It is required that the system administrator preallocate
> -enough memory for huge page purposes.
> -
> -The administrator can preallocate huge pages on the kernel boot command line by
> -specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
> -requested.  This is the most reliable method for preallocating huge pages as
> -memory has not yet become fragmented.
> +/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
> +allocated in the kernel's huge page pool.  These are called "persistent"
> +huge pages.  A user with root privileges can dynamically allocate more or
> +free some persistent huge pages by increasing or decreasing the value of
> +'nr_hugepages'.
> +

So they're not necessarily "preallocated" then if they're already in use.

> +Pages that are used as huge pages are reserved inside the kernel and cannot
> +be used for other purposes.  Huge pages can not be swapped out under
> +memory pressure.
> +
> +Once a number of huge pages have been pre-allocated to the kernel huge page
> +pool, a user with appropriate privilege can use either the mmap system call
> +or shared memory system calls to use the huge pages.  See the discussion of
> +Using Huge Pages, below
> +
> +The administrator can preallocate persistent huge pages on the kernel boot
> +command line by specifying the "hugepages=N" parameter, where 'N' = the
> +number of requested huge pages requested.  This is the most reliable method
> +or preallocating huge pages as memory has not yet become fragmented.
>  
>  Some platforms support multiple huge page sizes.  To preallocate huge pages
>  of a specific size, one must preceed the huge pages boot command parameters
> @@ -80,19 +77,24 @@ with a huge page size selection paramete
>  be specified in bytes with optional scale suffix [kKmMgG].  The default huge
>  page size may be selected with the "default_hugepagesz=<size>" boot parameter.
>  
> -/proc/sys/vm/nr_hugepages indicates the current number of configured [default
> -size] hugetlb pages in the kernel.  Super user can dynamically request more
> -(or free some pre-configured) huge pages.
> -
> -Use the following command to dynamically allocate/deallocate default sized
> -huge pages:
> +When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages
> +indicates the current number of pre-allocated huge pages of the default size.
> +Thus, one can use the following command to dynamically allocate/deallocate
> +default sized persistent huge pages:
>  
>  	echo 20 > /proc/sys/vm/nr_hugepages
>  
> -This command will try to configure 20 default sized huge pages in the system.
> +This command will try to adjust the number of default sized huge pages in the
> +huge page pool to 20, allocating or freeing huge pages, as required.
> +
>  On a NUMA platform, the kernel will attempt to distribute the huge page pool
> -over the all on-line nodes.  These huge pages, allocated when nr_hugepages
> -is increased, are called "persistent huge pages".
> +over the all the nodes specified by the NUMA memory policy of the task that

Remove the first 'the'.

> +modifies nr_hugepages that contain sufficient available contiguous memory.
> +These nodes are called the huge pages "allowed nodes".  The default for the

Not sure if you need to spell out that they're called "huge page allowed 
nodes," isn't that an implementation detail?  The way Paul Jackson used to 
describe nodes_allowed is "set of allowable nodes," and I can't think of a 
better phrase.  That's also how the cpuset documentation describes them.

> +huge pages allowed nodes--when the task has default memory policy--is all
> +on-line nodes.  See the discussion below of the interaction of task memory

All online nodes with memory, right?

> +policy, cpusets and per node attributes with the allocation and freeing of
> +persistent huge pages.
>  
>  The success or failure of huge page allocation depends on the amount of
>  physically contiguous memory that is preset in system at the time of the
> @@ -101,11 +103,11 @@ some nodes in a NUMA system, it will att
>  allocating extra pages on other nodes with sufficient available contiguous
>  memory, if any.
>  
> -System administrators may want to put this command in one of the local rc init
> -files.  This will enable the kernel to request huge pages early in the boot
> -process when the possibility of getting physical contiguous pages is still
> -very high.  Administrators can verify the number of huge pages actually
> -allocated by checking the sysctl or meminfo.  To check the per node
> +System administrators may want to put this command in one of the local rc
> +init files.  This will enable the kernel to preallocate huge pages early in
> +the boot process when the possibility of getting physical contiguous pages
> +is still very high.  Administrators can verify the number of huge pages
> +actually allocated by checking the sysctl or meminfo.  To check the per node
>  distribution of huge pages in a NUMA system, use:
>  
>  	cat /sys/devices/system/node/node*/meminfo | fgrep Huge
> @@ -113,39 +115,40 @@ distribution of huge pages in a NUMA sys
>  /proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of
>  huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are
>  requested by applications.  Writing any non-zero value into this file
> -indicates that the hugetlb subsystem is allowed to try to obtain "surplus"
> -huge pages from the buddy allocator, when the normal pool is exhausted. As
> -these surplus huge pages go out of use, they are freed back to the buddy
> -allocator.
> +indicates that the hugetlb subsystem is allowed to try to obtain that
> +number of "surplus" huge pages from the kernel's normal page pool, when the
> +persistent huge page pool is exhausted. As these surplus huge pages become
> +unused, they are freed back to the kernel's normal page pool.
>  
> -When increasing the huge page pool size via nr_hugepages, any surplus
> +When increasing the huge page pool size via nr_hugepages, any existing surplus
>  pages will first be promoted to persistent huge pages.  Then, additional
>  huge pages will be allocated, if necessary and if possible, to fulfill
> -the new huge page pool size.
> +the new persistent huge page pool size.
>  
>  The administrator may shrink the pool of preallocated huge pages for
>  the default huge page size by setting the nr_hugepages sysctl to a
>  smaller value.  The kernel will attempt to balance the freeing of huge pages
> -across all on-line nodes.  Any free huge pages on the selected nodes will
> -be freed back to the buddy allocator.
> -
> -Caveat: Shrinking the pool via nr_hugepages such that it becomes less
> -than the number of huge pages in use will convert the balance to surplus
> -huge pages even if it would exceed the overcommit value.  As long as
> -this condition holds, however, no more surplus huge pages will be
> -allowed on the system until one of the two sysctls are increased
> -sufficiently, or the surplus huge pages go out of use and are freed.
> +across all nodes in the memory policy of the task modifying nr_hugepages.
> +Any free huge pages on the selected nodes will be freed back to the kernel's
> +normal page pool.
> +
> +Caveat: Shrinking the persistent huge page pool via nr_hugepages such that
> +it becomes less than the number of huge pages in use will convert the balance
> +of the in-use huge pages to surplus huge pages.  This will occur even if
> +the number of surplus pages it would exceed the overcommit value.  As long as
> +this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is
> +increased sufficiently, or the surplus huge pages go out of use and are freed--
> +no more surplus huge pages will be allowed to be allocated.
>  

Nice description!

>  With support for multiple huge page pools at run-time available, much of
> -the huge page userspace interface has been duplicated in sysfs. The above
> -information applies to the default huge page size which will be
> -controlled by the /proc interfaces for backwards compatibility. The root
> -huge page control directory in sysfs is:
> +the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs.
> +The /proc interfaces discussed above have been retained for backwards
> +compatibility. The root huge page control directory in sysfs is:
>  
>  	/sys/kernel/mm/hugepages
>  
>  For each huge page size supported by the running kernel, a subdirectory
> -will exist, of the form
> +will exist, of the form:
>  
>  	hugepages-${size}kB
>  
> @@ -159,6 +162,98 @@ Inside each of these directories, the sa
>  
>  which function as described above for the default huge page-sized case.
>  
> +
> +Interaction of Task Memory Policy with Huge Page Allocation/Freeing:
> +
> +Whether huge pages are allocated and freed via the /proc interface or
> +the /sysfs interface, the NUMA nodes from which huge pages are allocated
> +or freed are controlled by the NUMA memory policy of the task that modifies
> +the nr_hugepages parameter.  [nr_overcommit_hugepages is a global limit.]
> +
> +The recommended method to allocate or free huge pages to/from the kernel
> +huge page pool, using the nr_hugepages example above, is:
> +
> +    numactl --interleave <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
> +
> +or, more succinctly:
> +
> +    numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
> +
> +This will allocate or free abs(20 - nr_hugepages) to or from the nodes
> +specified in <node-list>, depending on whether nr_hugepages is initially
> +less than or greater than 20, respectively.  No huge pages will be
> +allocated nor freed on any node not included in the specified <node-list>.
> +

This is actually why I was against the mempolicy approach to begin with: 
applications currently can free all hugepages on the system simply by 
writing to nr_hugepages, regardless of their mempolicy.  It's now possible 
that hugepages will remain allocated because they are on nodes disjoint 
from current->mempolicy->v.nodes.  I hope the advantages of this approach 
outweigh the potential userspace breakage of existing applications.

> +Any memory policy mode--bind, preferred, local or interleave--may be
> +used.  The effect on persistent huge page allocation will be as follows:
> +
> +1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt],
> +   persistent huge pages will be distributed across the node or nodes
> +   specified in the mempolicy as if "interleave" had been specified.
> +   However, if a node in the policy does not contain sufficient contiguous
> +   memory for a huge page, the allocation will not "fallback" to the nearest
> +   neighbor node with sufficient contiguous memory.  To do this would cause
> +   undesirable imbalance in the distribution of the huge page pool, or
> +   possibly, allocation of persistent huge pages on nodes not allowed by
> +   the task's memory policy.
> +

This is a good example of why the per-node tunables are helpful in case 
such a fallback is desired.

> +2) One or more nodes may be specified with the bind or interleave policy.
> +   If more than one node is specified with the preferred policy, only the
> +   lowest numeric id will be used.  Local policy will select the node where
> +   the task is running at the time the nodes_allowed mask is constructed.
> +
> +3) For local policy to be deterministic, the task must be bound to a cpu or
> +   cpus in a single node.  Otherwise, the task could be migrated to some
> +   other node at any time after launch and the resulting node will be
> +   indeterminate.  Thus, local policy is not very useful for this purpose.
> +   Any of the other mempolicy modes may be used to specify a single node.
> +
> +4) The nodes allowed mask will be derived from any non-default task mempolicy,
> +   whether this policy was set explicitly by the task itself or one of its
> +   ancestors, such as numactl.  This means that if the task is invoked from a
> +   shell with non-default policy, that policy will be used.  One can specify a
> +   node list of "all" with numactl --interleave or --membind [-m] to achieve
> +   interleaving over all nodes in the system or cpuset.
> +

Nice description.

> +5) Any task mempolicy specifed--e.g., using numactl--will be constrained by
> +   the resource limits of any cpuset in which the task runs.  Thus, there will
> +   be no way for a task with non-default policy running in a cpuset with a
> +   subset of the system nodes to allocate huge pages outside the cpuset
> +   without first moving to a cpuset that contains all of the desired nodes.
> +
> +6) Hugepages allocated at boot time always use the node_online_map.

Implementation detail in the name, maybe just say "all online nodes with 
memory"?

> +
> +
> +Per Node Hugepages Attributes
> +
> +A subset of the contents of the root huge page control directory in sysfs,
> +described above, has been replicated under each "node" system device in:
> +
> +	/sys/devices/system/node/node[0-9]*/hugepages/
> +
> +Under this directory, the subdirectory for each supported huge page size
> +contains the following attribute files:
> +
> +	nr_hugepages
> +	free_hugepages
> +	surplus_hugepages
> +
> +The free_' and surplus_' attribute files are read-only.  They return the number
> +of free and surplus [overcommitted] huge pages, respectively, on the parent
> +node.
> +
> +The nr_hugepages attribute will return the total number of huge pages on the
> +specified node.  When this attribute is written, the number of persistent huge
> +pages on the parent node will be adjusted to the specified value, if sufficient
> +resources exist, regardless of the task's mempolicy or cpuset constraints.
> +
> +Note that the number of overcommit and reserve pages remain global quantities,
> +as we don't know until fault time, when the faulting task's mempolicy is applied,
> +from which node the huge page allocation will be attempted.
> +
> +
> +Using Huge Pages:
> +
>  If the user applications are going to request huge pages using mmap system
>  call, then it is required that system administrator mount a file system of
>  type hugetlbfs:
> @@ -206,9 +301,11 @@ map_hugetlb.c.
>   * requesting huge pages.
>   *
>   * For the ia64 architecture, the Linux kernel reserves Region number 4 for
> - * huge pages.  That means the addresses starting with 0x800000... will need
> - * to be specified.  Specifying a fixed address is not required on ppc64,
> - * i386 or x86_64.
> + * huge pages.  That means that if one requires a fixed address, a huge page
> + * aligned address starting with 0x800000... will be required.  If a fixed
> + * address is not required, the kernel will select an address in the proper
> + * range.
> + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
>   *
>   * Note: The default shared memory limit is quite low on many kernels,
>   * you may need to increase it via:
> @@ -237,14 +334,8 @@ map_hugetlb.c.
>  
>  #define dprintf(x)  printf(x)
>  
> -/* Only ia64 requires this */
> -#ifdef __ia64__
> -#define ADDR (void *)(0x8000000000000000UL)
> -#define SHMAT_FLAGS (SHM_RND)
> -#else
> -#define ADDR (void *)(0x0UL)
> +#define ADDR (void *)(0x0UL)	/* let kernel choose address */
>  #define SHMAT_FLAGS (0)
> -#endif
>  
>  int main(void)
>  {
> @@ -302,10 +393,12 @@ int main(void)
>   * example, the app is requesting memory of size 256MB that is backed by
>   * huge pages.
>   *
> - * For ia64 architecture, Linux kernel reserves Region number 4 for huge pages.
> - * That means the addresses starting with 0x800000... will need to be
> - * specified.  Specifying a fixed address is not required on ppc64, i386
> - * or x86_64.
> + * For the ia64 architecture, the Linux kernel reserves Region number 4 for
> + * huge pages.  That means that if one requires a fixed address, a huge page
> + * aligned address starting with 0x800000... will be required.  If a fixed
> + * address is not required, the kernel will select an address in the proper
> + * range.
> + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
>   */
>  #include <stdlib.h>
>  #include <stdio.h>
> @@ -317,14 +410,8 @@ int main(void)
>  #define LENGTH (256UL*1024*1024)
>  #define PROTECTION (PROT_READ | PROT_WRITE)
>  
> -/* Only ia64 requires this */
> -#ifdef __ia64__
> -#define ADDR (void *)(0x8000000000000000UL)
> -#define FLAGS (MAP_SHARED | MAP_FIXED)
> -#else
> -#define ADDR (void *)(0x0UL)
> +#define ADDR (void *)(0x0UL)	/* let kernel choose address */
>  #define FLAGS (MAP_SHARED)
> -#endif
>  
>  void check_bytes(char *addr)
>  {
> 

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from
 task mempolicy
Date: Thu, 03 Sep 2009 16:15:40 -0400
Message-ID: <1252008940.6029.131.camel@useless.americas.hpqcorp.net>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160332.11080.74896.sendpatchset@localhost.localdomain>
	 <alpine.DEB.1.00.0909031212110.22173@chino.kir.corp.google.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <alpine.DEB.1.00.0909031212110.22173@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Thu, 2009-09-03 at 12:22 -0700, David Rientjes wrote:
> 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.

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

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


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
Date: Thu, 03 Sep 2009 16:41:25 -0400
Message-ID: <1252010485.6029.180.camel@useless.americas.hpqcorp.net>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
	 <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Thu, 2009-09-03 at 12:52 -0700, David Rientjes wrote:
> On Fri, 28 Aug 2009, Lee Schermerhorn wrote:
> 
> > Index: linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
> > ===================================================================
> > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/mm/hugetlb.c	2009-08-28 09:21:28.000000000 -0400
> > +++ linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c	2009-08-28 09:21:31.000000000 -0400
> > @@ -24,6 +24,7 @@
> >  #include <asm/io.h>
> >  
> >  #include <linux/hugetlb.h>
> > +#include <linux/node.h>
> >  #include "internal.h"
> >  
> >  const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
> > @@ -1245,7 +1246,8 @@ static int adjust_pool_surplus(struct hs
> >  }
> >  
> >  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> > -static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count)
> > +static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> > +								int nid)
> >  {
> >  	unsigned long min_count, ret;
> >  	nodemask_t *nodes_allowed;
> > @@ -1253,7 +1255,21 @@ static unsigned long set_max_huge_pages(
> >  	if (h->order >= MAX_ORDER)
> >  		return h->max_huge_pages;
> >  
> > -	nodes_allowed = huge_mpol_nodes_allowed();
> > +	if (nid == NO_NODEID_SPECIFIED)
> > +		nodes_allowed = huge_mpol_nodes_allowed();
> > +	else {
> > +		/*
> > +		 * incoming 'count' is for node 'nid' only, so
> > +		 * adjust count to global, but restrict alloc/free
> > +		 * to the specified node.
> > +		 */
> > +		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
> > +		nodes_allowed = alloc_nodemask_of_node(nid);
> > +		if (!nodes_allowed)
> > +			printk(KERN_WARNING "%s unable to allocate allowed "
> > +			       "nodes mask for huge page allocation/free.  "
> > +			       "Falling back to default.\n", current->comm);
> > +	}
> >  
> >  	/*
> >  	 * Increase the pool size
> > @@ -1329,51 +1345,71 @@ out:
> >  static struct kobject *hugepages_kobj;
> >  static struct kobject *hstate_kobjs[HUGE_MAX_HSTATE];
> >  
> > -static struct hstate *kobj_to_hstate(struct kobject *kobj)
> > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp);
> > +
> > +static struct hstate *kobj_to_hstate(struct kobject *kobj, int *nidp)
> >  {
> >  	int i;
> > +
> >  	for (i = 0; i < HUGE_MAX_HSTATE; i++)
> > -		if (hstate_kobjs[i] == kobj)
> > +		if (hstate_kobjs[i] == kobj) {
> > +			if (nidp)
> > +				*nidp = NO_NODEID_SPECIFIED;
> >  			return &hstates[i];
> > -	BUG();
> > -	return NULL;
> > +		}
> > +
> > +	return kobj_to_node_hstate(kobj, nidp);
> >  }
> >  
> >  static ssize_t nr_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > -	return sprintf(buf, "%lu\n", h->nr_huge_pages);
> > +	struct hstate *h;
> > +	unsigned long nr_huge_pages;
> > +	int nid;
> > +
> > +	h = kobj_to_hstate(kobj, &nid);
> > +	if (nid == NO_NODEID_SPECIFIED)
> > +		nr_huge_pages = h->nr_huge_pages;
> > +	else
> > +		nr_huge_pages = h->nr_huge_pages_node[nid];
> > +
> > +	return sprintf(buf, "%lu\n", nr_huge_pages);
> >  }
> > +
> >  static ssize_t nr_hugepages_store(struct kobject *kobj,
> > -		struct kobj_attribute *attr, const char *buf, size_t count)
> > +		struct kobj_attribute *attr, const char *buf, size_t len)
> >  {
> > +	unsigned long count;
> > +	struct hstate *h;
> > +	int nid;
> >  	int err;
> > -	unsigned long input;
> > -	struct hstate *h = kobj_to_hstate(kobj);
> >  
> > -	err = strict_strtoul(buf, 10, &input);
> > +	err = strict_strtoul(buf, 10, &count);
> >  	if (err)
> >  		return 0;
> >  
> > -	h->max_huge_pages = set_max_huge_pages(h, input);
> > +	h = kobj_to_hstate(kobj, &nid);
> > +	h->max_huge_pages = set_max_huge_pages(h, count, nid);
> >  
> > -	return count;
> > +	return len;
> >  }
> >  HSTATE_ATTR(nr_hugepages);
> >  
> >  static ssize_t nr_overcommit_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> > +
> >  	return sprintf(buf, "%lu\n", h->nr_overcommit_huge_pages);
> >  }
> > +
> >  static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
> >  		struct kobj_attribute *attr, const char *buf, size_t count)
> >  {
> >  	int err;
> >  	unsigned long input;
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> >  
> >  	err = strict_strtoul(buf, 10, &input);
> >  	if (err)
> > @@ -1390,15 +1426,24 @@ HSTATE_ATTR(nr_overcommit_hugepages);
> >  static ssize_t free_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > -	return sprintf(buf, "%lu\n", h->free_huge_pages);
> > +	struct hstate *h;
> > +	unsigned long free_huge_pages;
> > +	int nid;
> > +
> > +	h = kobj_to_hstate(kobj, &nid);
> > +	if (nid == NO_NODEID_SPECIFIED)
> > +		free_huge_pages = h->free_huge_pages;
> > +	else
> > +		free_huge_pages = h->free_huge_pages_node[nid];
> > +
> > +	return sprintf(buf, "%lu\n", free_huge_pages);
> >  }
> >  HSTATE_ATTR_RO(free_hugepages);
> >  
> >  static ssize_t resv_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > +	struct hstate *h = kobj_to_hstate(kobj, NULL);
> >  	return sprintf(buf, "%lu\n", h->resv_huge_pages);
> >  }
> >  HSTATE_ATTR_RO(resv_hugepages);
> > @@ -1406,8 +1451,17 @@ HSTATE_ATTR_RO(resv_hugepages);
> >  static ssize_t surplus_hugepages_show(struct kobject *kobj,
> >  					struct kobj_attribute *attr, char *buf)
> >  {
> > -	struct hstate *h = kobj_to_hstate(kobj);
> > -	return sprintf(buf, "%lu\n", h->surplus_huge_pages);
> > +	struct hstate *h;
> > +	unsigned long surplus_huge_pages;
> > +	int nid;
> > +
> > +	h = kobj_to_hstate(kobj, &nid);
> > +	if (nid == NO_NODEID_SPECIFIED)
> > +		surplus_huge_pages = h->surplus_huge_pages;
> > +	else
> > +		surplus_huge_pages = h->surplus_huge_pages_node[nid];
> > +
> > +	return sprintf(buf, "%lu\n", surplus_huge_pages);
> >  }
> >  HSTATE_ATTR_RO(surplus_hugepages);
> >  
> > @@ -1424,19 +1478,21 @@ static struct attribute_group hstate_att
> >  	.attrs = hstate_attrs,
> >  };
> >  
> > -static int __init hugetlb_sysfs_add_hstate(struct hstate *h)
> > +static int __init hugetlb_sysfs_add_hstate(struct hstate *h,
> > +				struct kobject *parent,
> > +				struct kobject **hstate_kobjs,
> > +				struct attribute_group *hstate_attr_group)
> >  {
> >  	int retval;
> > +	int hi = h - hstates;
> >  
> > -	hstate_kobjs[h - hstates] = kobject_create_and_add(h->name,
> > -							hugepages_kobj);
> > -	if (!hstate_kobjs[h - hstates])
> > +	hstate_kobjs[hi] = kobject_create_and_add(h->name, parent);
> > +	if (!hstate_kobjs[hi])
> >  		return -ENOMEM;
> >  
> > -	retval = sysfs_create_group(hstate_kobjs[h - hstates],
> > -							&hstate_attr_group);
> > +	retval = sysfs_create_group(hstate_kobjs[hi], hstate_attr_group);
> >  	if (retval)
> > -		kobject_put(hstate_kobjs[h - hstates]);
> > +		kobject_put(hstate_kobjs[hi]);
> >  
> >  	return retval;
> >  }
> > @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
> >  		return;
> >  
> >  	for_each_hstate(h) {
> > -		err = hugetlb_sysfs_add_hstate(h);
> > +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> > +					 hstate_kobjs, &hstate_attr_group);
> >  		if (err)
> >  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
> >  								h->name);
> >  	}
> >  }
> >  
> > +#ifdef CONFIG_NUMA
> > +
> > +struct node_hstate {
> > +	struct kobject		*hugepages_kobj;
> > +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> > +};
> > +struct node_hstate node_hstates[MAX_NUMNODES];
> > +
> > +static struct attribute *per_node_hstate_attrs[] = {
> > +	&nr_hugepages_attr.attr,
> > +	&free_hugepages_attr.attr,
> > +	&surplus_hugepages_attr.attr,
> > +	NULL,
> > +};
> > +
> > +static struct attribute_group per_node_hstate_attr_group = {
> > +	.attrs = per_node_hstate_attrs,
> > +};
> > +
> > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> > +{
> > +	int nid;
> > +
> > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > +		struct node_hstate *nhs = &node_hstates[nid];
> > +		int i;
> > +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> > +			if (nhs->hstate_kobjs[i] == kobj) {
> > +				if (nidp)
> > +					*nidp = nid;
> > +				return &hstates[i];
> > +			}
> > +	}
> > +
> > +	BUG();
> > +	return NULL;
> > +}
> > +
> > +void hugetlb_unregister_node(struct node *node)
> > +{
> > +	struct hstate *h;
> > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > +
> > +	if (!nhs->hugepages_kobj)
> > +		return;
> > +
> > +	for_each_hstate(h)
> > +		if (nhs->hstate_kobjs[h - hstates]) {
> > +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> > +			nhs->hstate_kobjs[h - hstates] = NULL;
> > +		}
> > +
> > +	kobject_put(nhs->hugepages_kobj);
> > +	nhs->hugepages_kobj = NULL;
> > +}
> > +
> > +static void hugetlb_unregister_all_nodes(void)
> > +{
> > +	int nid;
> > +
> > +	for (nid = 0; nid < nr_node_ids; nid++)
> > +		hugetlb_unregister_node(&node_devices[nid]);
> > +
> > +	register_hugetlbfs_with_node(NULL, NULL);
> > +}
> > +
> > +void hugetlb_register_node(struct node *node)
> > +{
> > +	struct hstate *h;
> > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > +	int err;
> > +
> > +	if (nhs->hugepages_kobj)
> > +		return;		/* already allocated */
> > +
> > +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> > +							&node->sysdev.kobj);
> > +	if (!nhs->hugepages_kobj)
> > +		return;
> > +
> > +	for_each_hstate(h) {
> > +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> > +						nhs->hstate_kobjs,
> > +						&per_node_hstate_attr_group);
> > +		if (err) {
> > +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> > +					" for node %d\n",
> > +						h->name, node->sysdev.id);
> 
> Maybe add `err' to the printk so we know whether it was an -ENOMEM 
> condition or sysfs problem?

Just the raw negative number?

> 
> > +			hugetlb_unregister_node(node);
> > +			break;
> > +		}
> > +	}
> > +}
> > +
> > +static void hugetlb_register_all_nodes(void)
> > +{
> > +	int nid;
> > +
> > +	for (nid = 0; nid < nr_node_ids; nid++) {
> 
> Don't you want to do this for all nodes in N_HIGH_MEMORY?  I don't think 
> we should be adding attributes for memoryless nodes.


Well, I wondered about that.  The persistent huge page allocation code
is careful to skip over nodes where it can't allow a huge page there,
whether or not the node has [any] memory.  So, it's safe to leave it
this way.  And, I was worried about the interaction with memory hotplug,
as separate from node hotplug.  The current code handles node hot plug,
bug I wasn't sure about memory hot-plug within a node.  I.e., would the
node driver get called to register the attributes in this case?   Maybe
that case doesn't exist, so I don't have to worry about it.   I think
this is somewhat similar to the top cpuset mems_allowed being set to all
possible to cover any subsequently added nodes/memory.

It's easy to change to use node_state[N_HIGH_MEMORY], but then the
memory hotplug guys might jump in and say that, now it doesn't work for
memory hot add/remove.  I really don't want to go there...

But, I can understand the confusion about providing an explicit control
like this for a node without memory.  It is somewhat different from just
visiting all online nodes for the default mask, as hugetlb.c has always
done.
  
> 
> > +		struct node *node = &node_devices[nid];
> > +		if (node->sysdev.id == nid)
> > +			hugetlb_register_node(node);
> > +	}
> > +
> > +	register_hugetlbfs_with_node(hugetlb_register_node,
> > +                                     hugetlb_unregister_node);
> > +}
> > +#else	/* !CONFIG_NUMA */
> > +
> > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> > +{
> > +	BUG();
> > +	if (nidp)
> > +		*nidp = -1;
> > +	return NULL;
> > +}
> > +
> > +static void hugetlb_unregister_all_nodes(void) { }
> > +
> > +static void hugetlb_register_all_nodes(void) { }
> > +
> > +#endif
> > +
> >  static void __exit hugetlb_exit(void)
> >  {
> >  	struct hstate *h;
> >  
> > +	hugetlb_unregister_all_nodes();
> > +
> >  	for_each_hstate(h) {
> >  		kobject_put(hstate_kobjs[h - hstates]);
> >  	}
> > @@ -1496,6 +1678,8 @@ static int __init hugetlb_init(void)
> >  
> >  	hugetlb_sysfs_init();
> >  
> > +	hugetlb_register_all_nodes();
> > +
> >  	return 0;
> >  }
> >  module_init(hugetlb_init);
> > @@ -1598,7 +1782,8 @@ int hugetlb_sysctl_handler(struct ctl_ta
> >  	proc_doulongvec_minmax(table, write, buffer, length, ppos);
> >  
> >  	if (write)
> > -		h->max_huge_pages = set_max_huge_pages(h, tmp);
> > +		h->max_huge_pages = set_max_huge_pages(h, tmp,
> > +		                                       NO_NODEID_SPECIFIED);
> >  
> >  	return 0;
> >  }
> > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
> > ===================================================================
> > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
> > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
> > @@ -10,4 +10,6 @@
> >  
> >  #define MAX_NUMNODES    (1 << NODES_SHIFT)
> >  
> > +#define NO_NODEID_SPECIFIED	(-1)
> > +
> >  #endif /* _LINUX_NUMA_H */
> 
> Hmm, so we already have NUMA_NO_NODE in the ia64 and x86_64 code and 
> NID_INVAL in the ACPI code, both of which are defined to -1.  Maybe rename 
> your addition here in favor of NUMA_NO_NODE, remove it from the ia64 and 
> x86 arch headers, and convert the ACPI code?

OK, replacing 'NO_NODEID_SPECIFIED' with 'NUMA_NO_NODE,' works w/o
decending into header dependency hell.  The symbol is already visible in
hugetlb.c  I'll fix that.  But, ACPI?  Not today, thanks :).  

> 
> Thanks for doing this!

Well, we do need this, as well.


From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 3/6] hugetlb:  derive huge pages nodes allowed from task
 mempolicy
Date: Thu, 3 Sep 2009 13:49:11 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909031342520.30662@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160332.11080.74896.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031212110.22173@chino.kir.corp.google.com>
 <1252008940.6029.131.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252010957; bh=QuUs2aiAafSN+LzVlmCpZ3U1vTc=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=S8Avr/6AbCkLrjVP3OBLiq1t1T2H8C7
	8CUBd4SVQ+YCDViM8xRxaqiOpierTzXFeqG4weTcW1fNO8QmRSbOH7g==
In-Reply-To: <1252008940.6029.131.camel@useless.americas.hpqcorp.net>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.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.  

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
Date: Thu, 3 Sep 2009 14:02:00 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909031350030.30662@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160344.11080.20255.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
 <1252010485.6029.180.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252011724; bh=LFvnnECGu/7Q+g2oWV9PEvek0So=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=gf6MWg8tNmt/4UugQ7kpiCV87kOOwio
	/pAqdOEmJoFbcymI4oC4xYhg03SqGnDVFbSlk2V3MN0XLzi+kMa/cQg==
In-Reply-To: <1252010485.6029.180.camel@useless.americas.hpqcorp.net>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Thu, 3 Sep 2009, Lee Schermerhorn wrote:

> > > @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
> > >  		return;
> > >  
> > >  	for_each_hstate(h) {
> > > -		err = hugetlb_sysfs_add_hstate(h);
> > > +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> > > +					 hstate_kobjs, &hstate_attr_group);
> > >  		if (err)
> > >  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
> > >  								h->name);
> > >  	}
> > >  }
> > >  
> > > +#ifdef CONFIG_NUMA
> > > +
> > > +struct node_hstate {
> > > +	struct kobject		*hugepages_kobj;
> > > +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> > > +};
> > > +struct node_hstate node_hstates[MAX_NUMNODES];
> > > +
> > > +static struct attribute *per_node_hstate_attrs[] = {
> > > +	&nr_hugepages_attr.attr,
> > > +	&free_hugepages_attr.attr,
> > > +	&surplus_hugepages_attr.attr,
> > > +	NULL,
> > > +};
> > > +
> > > +static struct attribute_group per_node_hstate_attr_group = {
> > > +	.attrs = per_node_hstate_attrs,
> > > +};
> > > +
> > > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> > > +{
> > > +	int nid;
> > > +
> > > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > > +		struct node_hstate *nhs = &node_hstates[nid];
> > > +		int i;
> > > +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> > > +			if (nhs->hstate_kobjs[i] == kobj) {
> > > +				if (nidp)
> > > +					*nidp = nid;
> > > +				return &hstates[i];
> > > +			}
> > > +	}
> > > +
> > > +	BUG();
> > > +	return NULL;
> > > +}
> > > +
> > > +void hugetlb_unregister_node(struct node *node)
> > > +{
> > > +	struct hstate *h;
> > > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > > +
> > > +	if (!nhs->hugepages_kobj)
> > > +		return;
> > > +
> > > +	for_each_hstate(h)
> > > +		if (nhs->hstate_kobjs[h - hstates]) {
> > > +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> > > +			nhs->hstate_kobjs[h - hstates] = NULL;
> > > +		}
> > > +
> > > +	kobject_put(nhs->hugepages_kobj);
> > > +	nhs->hugepages_kobj = NULL;
> > > +}
> > > +
> > > +static void hugetlb_unregister_all_nodes(void)
> > > +{
> > > +	int nid;
> > > +
> > > +	for (nid = 0; nid < nr_node_ids; nid++)
> > > +		hugetlb_unregister_node(&node_devices[nid]);
> > > +
> > > +	register_hugetlbfs_with_node(NULL, NULL);
> > > +}
> > > +
> > > +void hugetlb_register_node(struct node *node)
> > > +{
> > > +	struct hstate *h;
> > > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > > +	int err;
> > > +
> > > +	if (nhs->hugepages_kobj)
> > > +		return;		/* already allocated */
> > > +
> > > +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> > > +							&node->sysdev.kobj);
> > > +	if (!nhs->hugepages_kobj)
> > > +		return;
> > > +
> > > +	for_each_hstate(h) {
> > > +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> > > +						nhs->hstate_kobjs,
> > > +						&per_node_hstate_attr_group);
> > > +		if (err) {
> > > +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> > > +					" for node %d\n",
> > > +						h->name, node->sysdev.id);
> > 
> > Maybe add `err' to the printk so we know whether it was an -ENOMEM 
> > condition or sysfs problem?
> 
> Just the raw negative number?
> 

Sure.  I'm making the assumption that the printk is actually necessary in 
the first place, which is rather unorthodox for functions that can 
otherwise silently recover by unregistering the attribute.  Using the 
printk implies you want to know about the failure, yet additional 
debugging would be necessary to even identify what the failure was without 
printing the errno.

> > 
> > > +			hugetlb_unregister_node(node);
> > > +			break;
> > > +		}
> > > +	}
> > > +}
> > > +
> > > +static void hugetlb_register_all_nodes(void)
> > > +{
> > > +	int nid;
> > > +
> > > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > 
> > Don't you want to do this for all nodes in N_HIGH_MEMORY?  I don't think 
> > we should be adding attributes for memoryless nodes.
> 
> 
> Well, I wondered about that.  The persistent huge page allocation code
> is careful to skip over nodes where it can't allow a huge page there,
> whether or not the node has [any] memory.  So, it's safe to leave it
> this way.

It's safe, but it seems inconsistent to allow hugepage attributes to 
appear in /sys/devices/node/node* for nodes that have no memory.

> And, I was worried about the interaction with memory hotplug,
> as separate from node hotplug.  The current code handles node hot plug,
> bug I wasn't sure about memory hot-plug within a node.

If memory hotplug doesn't update nodes_state[N_HIGH_MEMORY] then there are 
plenty of other users that will currently fail as well.

> I.e., would the
> node driver get called to register the attributes in this case?

Not without a MEM_ONLINE notifier.

> Maybe
> that case doesn't exist, so I don't have to worry about it.   I think
> this is somewhat similar to the top cpuset mems_allowed being set to all
> possible to cover any subsequently added nodes/memory.
> 

That's because the page allocator's zonelists won't try to allocate from a 
memoryless node and the only hook into the cpuset code in that path is to 
check whether a nid is set in cpuset_current_mems_allowed.  It's quite 
different from providing per-node allocation and freeing mechanisms for 
pages on nodes without memory like this approach.

> > > Index: linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
> > > ===================================================================
> > > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/include/linux/numa.h	2009-08-28 09:21:17.000000000 -0400
> > > +++ linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h	2009-08-28 09:21:31.000000000 -0400
> > > @@ -10,4 +10,6 @@
> > >  
> > >  #define MAX_NUMNODES    (1 << NODES_SHIFT)
> > >  
> > > +#define NO_NODEID_SPECIFIED	(-1)
> > > +
> > >  #endif /* _LINUX_NUMA_H */
> > 
> > Hmm, so we already have NUMA_NO_NODE in the ia64 and x86_64 code and 
> > NID_INVAL in the ACPI code, both of which are defined to -1.  Maybe rename 
> > your addition here in favor of NUMA_NO_NODE, remove it from the ia64 and 
> > x86 arch headers, and convert the ACPI code?
> 
> OK, replacing 'NO_NODEID_SPECIFIED' with 'NUMA_NO_NODE,' works w/o
> decending into header dependency hell.  The symbol is already visible in
> hugetlb.c  I'll fix that.

NUMA_NO_NODE may be visible in hugetlb.c for ia64 and x86, but probably 
not for other architectures so it should be moved to include/linux/numa.h.

> But, ACPI?  Not today, thanks :).

Darn :)

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 4/6] hugetlb:  introduce alloc_nodemask_of_node
Date: Thu, 3 Sep 2009 14:03:55 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909031402340.30662@chino.kir.corp.google.com>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160338.11080.51282.sendpatchset@localhost.localdomain> <20090901144932.GB7548@csn.ul.ie> <1251823334.4164.2.camel@useless.americas.hpqcorp.net>
 <alpine.DEB.1.00.0909031122590.9055@chino.kir.corp.google.com> <1252010988.6029.194.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252011840; bh=rX/P9JQcxDaMUx233NWwEg8uQXQ=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=YUqqqxxAdYudlfGPDz9/47cDuwQ6dx7
	Qn3FmKgzi3La7HES9UGaLiV3BmYdE7Id15zOXds7qj3PE71ZkWX7n6g==
In-Reply-To: <1252010988.6029.194.camel@useless.americas.hpqcorp.net>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Thu, 3 Sep 2009, Lee Schermerhorn wrote:

> > I've seen the issue about the signed-off-by/reviewed-by/acked-by order 
> > come up before.  I've always put my signed-off-by line last whenever 
> > proposing patches because it shows a clear order in who gathered those 
> > lines when submitting to -mm, for example.  If I write
> > 
> > 	Cc: Mel Gorman <mel@csn.ul.ie>
> > 	Signed-off-by: David Rientjes <rientjes@google.com>
> > 
> > it is clear that I cc'd Mel on the initial proposal.  If it is the other 
> > way around, for example,
> > 
> > 	Signed-off-by: David Rientjes <rientjes@google.com>
> > 	Cc: Mel Gorman <mel@csn.ul.ie>
> > 	Signed-off-by: Andrew Morton...
> > 
> > then it indicates Andrew added the cc when merging into -mm.  That's more 
> > relevant when such a line is acked-by or reviewed-by since it is now 
> > possible to determine who received such acknowledgement from the 
> > individual and is responsible for correctly relaying it in the patch 
> > submission.
> > 
> > If it's done this way, it indicates that whoever is signing off the patch 
> > is responsible for everything above it.  The type of line (signed-off-by, 
> > reviewed-by, acked-by) is enough of an indication about the development 
> > history of the patch, I believe, and it doesn't require specific ordering 
> > to communicate (and the first line having to be a signed-off-by line isn't 
> > really important, it doesn't replace the From: line).
> > 
> > It also appears to be how both Linus merges his own patches with Cc's.
> 
> ???
> 

Not sure what's confusing about this, sorry.  You order your 
acked-by/reviewed-by/signed-off-by lines just like I have for years and I 
don't think it needs to be changed.  It shows a clear history of who did 
what in the path from original developer -> maintainer -> Linus.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
 mempolicy based management.
Date: Thu, 03 Sep 2009 17:09:18 -0400
Message-ID: <1252012158.6029.215.camel@useless.americas.hpqcorp.net>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160351.11080.21379.sendpatchset@localhost.localdomain>
	 <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com, Randy Dunlap <randy.dunlap@oracle.com>

On Thu, 2009-09-03 at 13:07 -0700, David Rientjes wrote:
> On Fri, 28 Aug 2009, Lee Schermerhorn wrote:
> 
> > [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy based management.
> > 
> > Against: 2.6.31-rc7-mmotm-090827-0057
> > 
> > V2:  Add brief description of per node attributes.
> > 
> > This patch updates the kernel huge tlb documentation to describe the
> > numa memory policy based huge page management.  Additionaly, the patch
> > includes a fair amount of rework to improve consistency, eliminate
> > duplication and set the context for documenting the memory policy
> > interaction.
> > 
> > Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 
> Adding Randy to the cc.  Comments below, but otherwise:
> 
> Acked-by: David Rientjes <rientjes@google.com>
> 
> > 
> >  Documentation/vm/hugetlbpage.txt |  257 ++++++++++++++++++++++++++-------------
> >  1 file changed, 172 insertions(+), 85 deletions(-)
> > 
> > Index: linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt
> > ===================================================================
> > --- linux-2.6.31-rc7-mmotm-090827-0057.orig/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:16.000000000 -0400
> > +++ linux-2.6.31-rc7-mmotm-090827-0057/Documentation/vm/hugetlbpage.txt	2009-08-28 09:21:32.000000000 -0400
> > @@ -11,23 +11,21 @@ This optimization is more critical now a
> >  (several GBs) are more readily available.
> >  
> >  Users can use the huge page support in Linux kernel by either using the mmap
> > -system call or standard SYSv shared memory system calls (shmget, shmat).
> > +system call or standard SYSV shared memory system calls (shmget, shmat).
> >  
> >  First the Linux kernel needs to be built with the CONFIG_HUGETLBFS
> >  (present under "File systems") and CONFIG_HUGETLB_PAGE (selected
> >  automatically when CONFIG_HUGETLBFS is selected) configuration
> >  options.
> >  
> > -The kernel built with huge page support should show the number of configured
> > -huge pages in the system by running the "cat /proc/meminfo" command.
> > +The /proc/meminfo file provides information about the total number of hugetlb
> > +pages preallocated in the kernel's huge page pool.  It also displays
> > +information about the number of free, reserved and surplus huge pages and the
> > +[default] huge page size.  The huge page size is needed for generating the
> 
> Don't think the brackets are needed.

will fix

> 
> > +proper alignment and size of the arguments to system calls that map huge page
> > +regions.
> >  
> > -/proc/meminfo also provides information about the total number of hugetlb
> > -pages configured in the kernel.  It also displays information about the
> > -number of free hugetlb pages at any time.  It also displays information about
> > -the configured huge page size - this is needed for generating the proper
> > -alignment and size of the arguments to the above system calls.
> > -
> > -The output of "cat /proc/meminfo" will have lines like:
> > +The output of "cat /proc/meminfo" will include lines like:
> >  
> >  .....
> >  HugePages_Total: vvv
> > @@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
> >  /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
> >  in the kernel.
> >  
> > -/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
> > -pages in the kernel.  Super user can dynamically request more (or free some
> > -pre-configured) huge pages.
> > -The allocation (or deallocation) of hugetlb pages is possible only if there are
> > -enough physically contiguous free pages in system (freeing of huge pages is
> > -possible only if there are enough hugetlb pages free that can be transferred
> > -back to regular memory pool).
> > -
> > -Pages that are used as hugetlb pages are reserved inside the kernel and cannot
> > -be used for other purposes.
> > -
> > -Once the kernel with Hugetlb page support is built and running, a user can
> > -use either the mmap system call or shared memory system calls to start using
> > -the huge pages.  It is required that the system administrator preallocate
> > -enough memory for huge page purposes.
> > -
> > -The administrator can preallocate huge pages on the kernel boot command line by
> > -specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
> > -requested.  This is the most reliable method for preallocating huge pages as
> > -memory has not yet become fragmented.
> > +/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
> > +allocated in the kernel's huge page pool.  These are called "persistent"
> > +huge pages.  A user with root privileges can dynamically allocate more or
> > +free some persistent huge pages by increasing or decreasing the value of
> > +'nr_hugepages'.
> > +
> 
> So they're not necessarily "preallocated" then if they're already in use.

I don't see what in the text you're referring to"  "preallocated" vs
"already in use" ???

> 
> > +Pages that are used as huge pages are reserved inside the kernel and cannot
> > +be used for other purposes.  Huge pages can not be swapped out under
> > +memory pressure.
> > +
> > +Once a number of huge pages have been pre-allocated to the kernel huge page
> > +pool, a user with appropriate privilege can use either the mmap system call
> > +or shared memory system calls to use the huge pages.  See the discussion of
> > +Using Huge Pages, below
> > +
> > +The administrator can preallocate persistent huge pages on the kernel boot
> > +command line by specifying the "hugepages=N" parameter, where 'N' = the
> > +number of requested huge pages requested.  This is the most reliable method
> > +or preallocating huge pages as memory has not yet become fragmented.
> >  
> >  Some platforms support multiple huge page sizes.  To preallocate huge pages
> >  of a specific size, one must preceed the huge pages boot command parameters
> > @@ -80,19 +77,24 @@ with a huge page size selection paramete
> >  be specified in bytes with optional scale suffix [kKmMgG].  The default huge
> >  page size may be selected with the "default_hugepagesz=<size>" boot parameter.
> >  
> > -/proc/sys/vm/nr_hugepages indicates the current number of configured [default
> > -size] hugetlb pages in the kernel.  Super user can dynamically request more
> > -(or free some pre-configured) huge pages.
> > -
> > -Use the following command to dynamically allocate/deallocate default sized
> > -huge pages:
> > +When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages
> > +indicates the current number of pre-allocated huge pages of the default size.
> > +Thus, one can use the following command to dynamically allocate/deallocate
> > +default sized persistent huge pages:
> >  
> >  	echo 20 > /proc/sys/vm/nr_hugepages
> >  
> > -This command will try to configure 20 default sized huge pages in the system.
> > +This command will try to adjust the number of default sized huge pages in the
> > +huge page pool to 20, allocating or freeing huge pages, as required.
> > +
> >  On a NUMA platform, the kernel will attempt to distribute the huge page pool
> > -over the all on-line nodes.  These huge pages, allocated when nr_hugepages
> > -is increased, are called "persistent huge pages".
> > +over the all the nodes specified by the NUMA memory policy of the task that
> 
> Remove the first 'the'.

OK.

> 
> > +modifies nr_hugepages that contain sufficient available contiguous memory.
> > +These nodes are called the huge pages "allowed nodes".  The default for the
> 
> Not sure if you need to spell out that they're called "huge page allowed 
> nodes," isn't that an implementation detail?  The way Paul Jackson used to 
> describe nodes_allowed is "set of allowable nodes," and I can't think of a 
> better phrase.  That's also how the cpuset documentation describes them.

I wanted to refer to "huge pages allowed nodes" to differentiate from,
e.g., cpusets mems_allowed"--i.e., I wanted the "huge pages" qualifier.
I suppose I could introduce the phrase you suggest:  "set of allowable
nodes" and emphasize that in this doc, it only refers to nodes from
which persistent huge pages will be allocated.

> 
> > +huge pages allowed nodes--when the task has default memory policy--is all
> > +on-line nodes.  See the discussion below of the interaction of task memory
> 
> All online nodes with memory, right?

See response to comment on patch 5/6.  We can only allocate huge pages
from nodes that have them available, but the current code [before these
patches] does visit all on-line nodes.  As I mentioned, changing this
could have hotplug {imp|comp}lications, and for this patch set, I don't
want to go there.

> 
> > +policy, cpusets and per node attributes with the allocation and freeing of
> > +persistent huge pages.
> >  
> >  The success or failure of huge page allocation depends on the amount of
> >  physically contiguous memory that is preset in system at the time of the
> > @@ -101,11 +103,11 @@ some nodes in a NUMA system, it will att
> >  allocating extra pages on other nodes with sufficient available contiguous
> >  memory, if any.
> >  
> > -System administrators may want to put this command in one of the local rc init
> > -files.  This will enable the kernel to request huge pages early in the boot
> > -process when the possibility of getting physical contiguous pages is still
> > -very high.  Administrators can verify the number of huge pages actually
> > -allocated by checking the sysctl or meminfo.  To check the per node
> > +System administrators may want to put this command in one of the local rc
> > +init files.  This will enable the kernel to preallocate huge pages early in
> > +the boot process when the possibility of getting physical contiguous pages
> > +is still very high.  Administrators can verify the number of huge pages
> > +actually allocated by checking the sysctl or meminfo.  To check the per node
> >  distribution of huge pages in a NUMA system, use:
> >  
> >  	cat /sys/devices/system/node/node*/meminfo | fgrep Huge
> > @@ -113,39 +115,40 @@ distribution of huge pages in a NUMA sys
> >  /proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of
> >  huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are
> >  requested by applications.  Writing any non-zero value into this file
> > -indicates that the hugetlb subsystem is allowed to try to obtain "surplus"
> > -huge pages from the buddy allocator, when the normal pool is exhausted. As
> > -these surplus huge pages go out of use, they are freed back to the buddy
> > -allocator.
> > +indicates that the hugetlb subsystem is allowed to try to obtain that
> > +number of "surplus" huge pages from the kernel's normal page pool, when the
> > +persistent huge page pool is exhausted. As these surplus huge pages become
> > +unused, they are freed back to the kernel's normal page pool.
> >  
> > -When increasing the huge page pool size via nr_hugepages, any surplus
> > +When increasing the huge page pool size via nr_hugepages, any existing surplus
> >  pages will first be promoted to persistent huge pages.  Then, additional
> >  huge pages will be allocated, if necessary and if possible, to fulfill
> > -the new huge page pool size.
> > +the new persistent huge page pool size.
> >  
> >  The administrator may shrink the pool of preallocated huge pages for
> >  the default huge page size by setting the nr_hugepages sysctl to a
> >  smaller value.  The kernel will attempt to balance the freeing of huge pages
> > -across all on-line nodes.  Any free huge pages on the selected nodes will
> > -be freed back to the buddy allocator.
> > -
> > -Caveat: Shrinking the pool via nr_hugepages such that it becomes less
> > -than the number of huge pages in use will convert the balance to surplus
> > -huge pages even if it would exceed the overcommit value.  As long as
> > -this condition holds, however, no more surplus huge pages will be
> > -allowed on the system until one of the two sysctls are increased
> > -sufficiently, or the surplus huge pages go out of use and are freed.
> > +across all nodes in the memory policy of the task modifying nr_hugepages.
> > +Any free huge pages on the selected nodes will be freed back to the kernel's
> > +normal page pool.
> > +
> > +Caveat: Shrinking the persistent huge page pool via nr_hugepages such that
> > +it becomes less than the number of huge pages in use will convert the balance
> > +of the in-use huge pages to surplus huge pages.  This will occur even if
> > +the number of surplus pages it would exceed the overcommit value.  As long as
> > +this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is
> > +increased sufficiently, or the surplus huge pages go out of use and are freed--
> > +no more surplus huge pages will be allowed to be allocated.
> >  
> 
> Nice description!
> 
> >  With support for multiple huge page pools at run-time available, much of
> > -the huge page userspace interface has been duplicated in sysfs. The above
> > -information applies to the default huge page size which will be
> > -controlled by the /proc interfaces for backwards compatibility. The root
> > -huge page control directory in sysfs is:
> > +the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs.
> > +The /proc interfaces discussed above have been retained for backwards
> > +compatibility. The root huge page control directory in sysfs is:
> >  
> >  	/sys/kernel/mm/hugepages
> >  
> >  For each huge page size supported by the running kernel, a subdirectory
> > -will exist, of the form
> > +will exist, of the form:
> >  
> >  	hugepages-${size}kB
> >  
> > @@ -159,6 +162,98 @@ Inside each of these directories, the sa
> >  
> >  which function as described above for the default huge page-sized case.
> >  
> > +
> > +Interaction of Task Memory Policy with Huge Page Allocation/Freeing:
> > +
> > +Whether huge pages are allocated and freed via the /proc interface or
> > +the /sysfs interface, the NUMA nodes from which huge pages are allocated
> > +or freed are controlled by the NUMA memory policy of the task that modifies
> > +the nr_hugepages parameter.  [nr_overcommit_hugepages is a global limit.]
> > +
> > +The recommended method to allocate or free huge pages to/from the kernel
> > +huge page pool, using the nr_hugepages example above, is:
> > +
> > +    numactl --interleave <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
> > +
> > +or, more succinctly:
> > +
> > +    numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
> > +
> > +This will allocate or free abs(20 - nr_hugepages) to or from the nodes
> > +specified in <node-list>, depending on whether nr_hugepages is initially
> > +less than or greater than 20, respectively.  No huge pages will be
> > +allocated nor freed on any node not included in the specified <node-list>.
> > +
> 
> This is actually why I was against the mempolicy approach to begin with: 
> applications currently can free all hugepages on the system simply by 
> writing to nr_hugepages, regardless of their mempolicy.  It's now possible 
> that hugepages will remain allocated because they are on nodes disjoint 
> from current->mempolicy->v.nodes.  I hope the advantages of this approach 
> outweigh the potential userspace breakage of existing applications.

I understand.  However, I do think it's useful to support both a mask
[and Mel prefers it be based on mempolicy] and per node attributes.  On
some of our platforms, we do want explicit control over the placement of
huge pages--e.g., for a data base shared area or such.  So, we can say,
"I need <N> huge pages, and I want them on nodes 1, 3, 4 and 5", and
then, assuming we start with no huge pages allocated [free them all if
this is not the case]:

	numactl -m 1,3-5 hugeadm --pool-pages-min 2M:<N>

Later, if I decide that maybe I want to adjust the number on node 1, I
can:

	numactl -m 1 --pool-pages-min 2M:{+|-}<count>

or:

	echo <new-value> >/sys/devices/system/node/node1/hugepages/hugepages-2048KB/nr_hugepages

[Of course, I'd probably do this in a script to avoid all that typing :)]

> > +Any memory policy mode--bind, preferred, local or interleave--may be
> > +used.  The effect on persistent huge page allocation will be as follows:
> > +
> > +1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt],
> > +   persistent huge pages will be distributed across the node or nodes
> > +   specified in the mempolicy as if "interleave" had been specified.
> > +   However, if a node in the policy does not contain sufficient contiguous
> > +   memory for a huge page, the allocation will not "fallback" to the nearest
> > +   neighbor node with sufficient contiguous memory.  To do this would cause
> > +   undesirable imbalance in the distribution of the huge page pool, or
> > +   possibly, allocation of persistent huge pages on nodes not allowed by
> > +   the task's memory policy.
> > +
> 
> This is a good example of why the per-node tunables are helpful in case 
> such a fallback is desired.

Agreed.  And the fact that they do bypass any mempolicy.

> 
> > +2) One or more nodes may be specified with the bind or interleave policy.
> > +   If more than one node is specified with the preferred policy, only the
> > +   lowest numeric id will be used.  Local policy will select the node where
> > +   the task is running at the time the nodes_allowed mask is constructed.
> > +
> > +3) For local policy to be deterministic, the task must be bound to a cpu or
> > +   cpus in a single node.  Otherwise, the task could be migrated to some
> > +   other node at any time after launch and the resulting node will be
> > +   indeterminate.  Thus, local policy is not very useful for this purpose.
> > +   Any of the other mempolicy modes may be used to specify a single node.
> > +
> > +4) The nodes allowed mask will be derived from any non-default task mempolicy,
> > +   whether this policy was set explicitly by the task itself or one of its
> > +   ancestors, such as numactl.  This means that if the task is invoked from a
> > +   shell with non-default policy, that policy will be used.  One can specify a
> > +   node list of "all" with numactl --interleave or --membind [-m] to achieve
> > +   interleaving over all nodes in the system or cpuset.
> > +
> 
> Nice description.
> 
> > +5) Any task mempolicy specifed--e.g., using numactl--will be constrained by
> > +   the resource limits of any cpuset in which the task runs.  Thus, there will
> > +   be no way for a task with non-default policy running in a cpuset with a
> > +   subset of the system nodes to allocate huge pages outside the cpuset
> > +   without first moving to a cpuset that contains all of the desired nodes.
> > +
> > +6) Hugepages allocated at boot time always use the node_online_map.
> 
> Implementation detail in the name, maybe just say "all online nodes with 
> memory"?

OK.  will fix for V6.  soon come, I hope.

> 
> > +
> > +
> > +Per Node Hugepages Attributes
> > +
> > +A subset of the contents of the root huge page control directory in sysfs,
> > +described above, has been replicated under each "node" system device in:
> > +
> > +	/sys/devices/system/node/node[0-9]*/hugepages/
> > +
> > +Under this directory, the subdirectory for each supported huge page size
> > +contains the following attribute files:
> > +
> > +	nr_hugepages
> > +	free_hugepages
> > +	surplus_hugepages
> > +
> > +The free_' and surplus_' attribute files are read-only.  They return the number
> > +of free and surplus [overcommitted] huge pages, respectively, on the parent
> > +node.
> > +
> > +The nr_hugepages attribute will return the total number of huge pages on the
> > +specified node.  When this attribute is written, the number of persistent huge
> > +pages on the parent node will be adjusted to the specified value, if sufficient
> > +resources exist, regardless of the task's mempolicy or cpuset constraints.
> > +
> > +Note that the number of overcommit and reserve pages remain global quantities,
> > +as we don't know until fault time, when the faulting task's mempolicy is applied,
> > +from which node the huge page allocation will be attempted.
> > +
> > +
> > +Using Huge Pages:
> > +
> >  If the user applications are going to request huge pages using mmap system
> >  call, then it is required that system administrator mount a file system of
> >  type hugetlbfs:
> > @@ -206,9 +301,11 @@ map_hugetlb.c.
> >   * requesting huge pages.
> >   *
> >   * For the ia64 architecture, the Linux kernel reserves Region number 4 for
> > - * huge pages.  That means the addresses starting with 0x800000... will need
> > - * to be specified.  Specifying a fixed address is not required on ppc64,
> > - * i386 or x86_64.
> > + * huge pages.  That means that if one requires a fixed address, a huge page
> > + * aligned address starting with 0x800000... will be required.  If a fixed
> > + * address is not required, the kernel will select an address in the proper
> > + * range.
> > + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
> >   *
> >   * Note: The default shared memory limit is quite low on many kernels,
> >   * you may need to increase it via:
> > @@ -237,14 +334,8 @@ map_hugetlb.c.
> >  
> >  #define dprintf(x)  printf(x)
> >  
> > -/* Only ia64 requires this */
> > -#ifdef __ia64__
> > -#define ADDR (void *)(0x8000000000000000UL)
> > -#define SHMAT_FLAGS (SHM_RND)
> > -#else
> > -#define ADDR (void *)(0x0UL)
> > +#define ADDR (void *)(0x0UL)	/* let kernel choose address */
> >  #define SHMAT_FLAGS (0)
> > -#endif
> >  
> >  int main(void)
> >  {
> > @@ -302,10 +393,12 @@ int main(void)
> >   * example, the app is requesting memory of size 256MB that is backed by
> >   * huge pages.
> >   *
> > - * For ia64 architecture, Linux kernel reserves Region number 4 for huge pages.
> > - * That means the addresses starting with 0x800000... will need to be
> > - * specified.  Specifying a fixed address is not required on ppc64, i386
> > - * or x86_64.
> > + * For the ia64 architecture, the Linux kernel reserves Region number 4 for
> > + * huge pages.  That means that if one requires a fixed address, a huge page
> > + * aligned address starting with 0x800000... will be required.  If a fixed
> > + * address is not required, the kernel will select an address in the proper
> > + * range.
> > + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
> >   */
> >  #include <stdlib.h>
> >  #include <stdio.h>
> > @@ -317,14 +410,8 @@ int main(void)
> >  #define LENGTH (256UL*1024*1024)
> >  #define PROTECTION (PROT_READ | PROT_WRITE)
> >  
> > -/* Only ia64 requires this */
> > -#ifdef __ia64__
> > -#define ADDR (void *)(0x8000000000000000UL)
> > -#define FLAGS (MAP_SHARED | MAP_FIXED)
> > -#else
> > -#define ADDR (void *)(0x0UL)
> > +#define ADDR (void *)(0x0UL)	/* let kernel choose address */
> >  #define FLAGS (MAP_SHARED)
> > -#endif
> >  
> >  void check_bytes(char *addr)
> >  {
> > 


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 5/6] hugetlb:  add per node hstate attributes
Date: Fri, 04 Sep 2009 10:30:47 -0400
Message-ID: <1252074647.4389.46.camel@useless.americas.hpqcorp.net>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain>
	 <20090828160344.11080.20255.sendpatchset@localhost.localdomain>
	 <alpine.DEB.1.00.0909031241160.24821@chino.kir.corp.google.com>
	 <1252010485.6029.180.camel@useless.americas.hpqcorp.net>
	 <alpine.DEB.1.00.0909031350030.30662@chino.kir.corp.google.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <alpine.DEB.1.00.0909031350030.30662@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com

On Thu, 2009-09-03 at 14:02 -0700, David Rientjes wrote:
> On Thu, 3 Sep 2009, Lee Schermerhorn wrote:
> 
> > > > @@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(vo
> > > >  		return;
> > > >  
> > > >  	for_each_hstate(h) {
> > > > -		err = hugetlb_sysfs_add_hstate(h);
> > > > +		err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> > > > +					 hstate_kobjs, &hstate_attr_group);
> > > >  		if (err)
> > > >  			printk(KERN_ERR "Hugetlb: Unable to add hstate %s",
> > > >  								h->name);
> > > >  	}
> > > >  }
> > > >  
> > > > +#ifdef CONFIG_NUMA
> > > > +
> > > > +struct node_hstate {
> > > > +	struct kobject		*hugepages_kobj;
> > > > +	struct kobject		*hstate_kobjs[HUGE_MAX_HSTATE];
> > > > +};
> > > > +struct node_hstate node_hstates[MAX_NUMNODES];
> > > > +
> > > > +static struct attribute *per_node_hstate_attrs[] = {
> > > > +	&nr_hugepages_attr.attr,
> > > > +	&free_hugepages_attr.attr,
> > > > +	&surplus_hugepages_attr.attr,
> > > > +	NULL,
> > > > +};
> > > > +
> > > > +static struct attribute_group per_node_hstate_attr_group = {
> > > > +	.attrs = per_node_hstate_attrs,
> > > > +};
> > > > +
> > > > +static struct hstate *kobj_to_node_hstate(struct kobject *kobj, int *nidp)
> > > > +{
> > > > +	int nid;
> > > > +
> > > > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > > > +		struct node_hstate *nhs = &node_hstates[nid];
> > > > +		int i;
> > > > +		for (i = 0; i < HUGE_MAX_HSTATE; i++)
> > > > +			if (nhs->hstate_kobjs[i] == kobj) {
> > > > +				if (nidp)
> > > > +					*nidp = nid;
> > > > +				return &hstates[i];
> > > > +			}
> > > > +	}
> > > > +
> > > > +	BUG();
> > > > +	return NULL;
> > > > +}
> > > > +
> > > > +void hugetlb_unregister_node(struct node *node)
> > > > +{
> > > > +	struct hstate *h;
> > > > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > > > +
> > > > +	if (!nhs->hugepages_kobj)
> > > > +		return;
> > > > +
> > > > +	for_each_hstate(h)
> > > > +		if (nhs->hstate_kobjs[h - hstates]) {
> > > > +			kobject_put(nhs->hstate_kobjs[h - hstates]);
> > > > +			nhs->hstate_kobjs[h - hstates] = NULL;
> > > > +		}
> > > > +
> > > > +	kobject_put(nhs->hugepages_kobj);
> > > > +	nhs->hugepages_kobj = NULL;
> > > > +}
> > > > +
> > > > +static void hugetlb_unregister_all_nodes(void)
> > > > +{
> > > > +	int nid;
> > > > +
> > > > +	for (nid = 0; nid < nr_node_ids; nid++)
> > > > +		hugetlb_unregister_node(&node_devices[nid]);
> > > > +
> > > > +	register_hugetlbfs_with_node(NULL, NULL);
> > > > +}
> > > > +
> > > > +void hugetlb_register_node(struct node *node)
> > > > +{
> > > > +	struct hstate *h;
> > > > +	struct node_hstate *nhs = &node_hstates[node->sysdev.id];
> > > > +	int err;
> > > > +
> > > > +	if (nhs->hugepages_kobj)
> > > > +		return;		/* already allocated */
> > > > +
> > > > +	nhs->hugepages_kobj = kobject_create_and_add("hugepages",
> > > > +							&node->sysdev.kobj);
> > > > +	if (!nhs->hugepages_kobj)
> > > > +		return;
> > > > +
> > > > +	for_each_hstate(h) {
> > > > +		err = hugetlb_sysfs_add_hstate(h, nhs->hugepages_kobj,
> > > > +						nhs->hstate_kobjs,
> > > > +						&per_node_hstate_attr_group);
> > > > +		if (err) {
> > > > +			printk(KERN_ERR "Hugetlb: Unable to add hstate %s"
> > > > +					" for node %d\n",
> > > > +						h->name, node->sysdev.id);
> > > 
> > > Maybe add `err' to the printk so we know whether it was an -ENOMEM 
> > > condition or sysfs problem?
> > 
> > Just the raw negative number?
> > 
> 
> Sure.  I'm making the assumption that the printk is actually necessary in 
> the first place, which is rather unorthodox for functions that can 
> otherwise silently recover by unregistering the attribute.  Using the 
> printk implies you want to know about the failure, yet additional 
> debugging would be necessary to even identify what the failure was without 
> printing the errno.


David:  


I'm going to leave this printk as is.  I want to keep it, because the
global hstate function issues a similar printk [w/o] error code when it
can't add a global hstate.  The original authors considered this
necessary/useful, so I'm following suit.  The -ENOMEM error is returned
by hugetlb_sysfs_add_hstate() when kobject_create_and_add().  If the
kobject creation can fail for reasons other than ENOMEM, then showing
ENOMEM in the message will sometimes be bogus.  If it can only fail due
to lack of memory, then we are adding no additional info.

more below

> 
> > > 
> > > > +			hugetlb_unregister_node(node);
> > > > +			break;
> > > > +		}
> > > > +	}
> > > > +}
> > > > +
> > > > +static void hugetlb_register_all_nodes(void)
> > > > +{
> > > > +	int nid;
> > > > +
> > > > +	for (nid = 0; nid < nr_node_ids; nid++) {
> > > 
> > > Don't you want to do this for all nodes in N_HIGH_MEMORY?  I don't think 
> > > we should be adding attributes for memoryless nodes.
> > 
> > 
> > Well, I wondered about that.  The persistent huge page allocation code
> > is careful to skip over nodes where it can't allow a huge page there,
> > whether or not the node has [any] memory.  So, it's safe to leave it
> > this way.
> 
> It's safe, but it seems inconsistent to allow hugepage attributes to 
> appear in /sys/devices/node/node* for nodes that have no memory.

OK.  I'm going to change this, and replace node_online_map with
node_state[N_HIGH_MEMORY] [or whatever] as a separate patch.  That way,
if someone complains that this doesn't work for memory hot plug, someone
who understands memory hotplut can fix it or we can drop that patch.

> 
> > And, I was worried about the interaction with memory hotplug,
> > as separate from node hotplug.  The current code handles node hot plug,
> > bug I wasn't sure about memory hot-plug within a node.
> 
> If memory hotplug doesn't update nodes_state[N_HIGH_MEMORY] then there are 
> plenty of other users that will currently fail as well.
> 
> > I.e., would the
> > node driver get called to register the attributes in this case?
> 
> Not without a MEM_ONLINE notifier.

That's what I thought.  I'm not up to speed on that area, and have no
bandwidth nor interest to go there, right now.  If you think that's a
show stopper for per node attributes, we can defer this part of the
series.  But, I'd prefer to stick with current "no-op" attributes for
memoryless nodes over that alternative.

> 
> > Maybe
> > that case doesn't exist, so I don't have to worry about it.   I think
> > this is somewhat similar to the top cpuset mems_allowed being set to all
> > possible to cover any subsequently added nodes/memory.
> > 
> 
> That's because the page allocator's zonelists won't try to allocate from a 
> memoryless node and the only hook into the cpuset code in that path is to 
> check whether a nid is set in cpuset_current_mems_allowed.  It's quite 
> different from providing per-node allocation and freeing mechanisms for 
> pages on nodes without memory like this approach.

OK, we have different perspectives on this.  I'm not at all offended by
the no-op attributes.  If you're worried about safety, I can check
explicitly in the attribute handlers and bail out early for memoryless
nodes.  Then, should someone hot add memory to the node, it will start
attemping to allocate huge pages when requested.

> 



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Date: Tue, 8 Sep 2009 11:44:09 +0100
Message-ID: <20090908104409.GB28127@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, eric.whitney@hp.com, Randy Dunlap <randy.dunlap@oracle.com>

On Thu, Sep 03, 2009 at 02:25:56PM -0700, David Rientjes wrote:
> On Thu, 3 Sep 2009, Lee Schermerhorn wrote:
> 
> > > > @@ -53,26 +51,25 @@ HugePages_Surp  is short for "surplus,"
> > > >  /proc/filesystems should also show a filesystem of type "hugetlbfs" configured
> > > >  in the kernel.
> > > >  
> > > > -/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
> > > > -pages in the kernel.  Super user can dynamically request more (or free some
> > > > -pre-configured) huge pages.
> > > > -The allocation (or deallocation) of hugetlb pages is possible only if there are
> > > > -enough physically contiguous free pages in system (freeing of huge pages is
> > > > -possible only if there are enough hugetlb pages free that can be transferred
> > > > -back to regular memory pool).
> > > > -
> > > > -Pages that are used as hugetlb pages are reserved inside the kernel and cannot
> > > > -be used for other purposes.
> > > > -
> > > > -Once the kernel with Hugetlb page support is built and running, a user can
> > > > -use either the mmap system call or shared memory system calls to start using
> > > > -the huge pages.  It is required that the system administrator preallocate
> > > > -enough memory for huge page purposes.
> > > > -
> > > > -The administrator can preallocate huge pages on the kernel boot command line by
> > > > -specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
> > > > -requested.  This is the most reliable method for preallocating huge pages as
> > > > -memory has not yet become fragmented.
> > > > +/proc/sys/vm/nr_hugepages indicates the current number of huge pages pre-
> > > > +allocated in the kernel's huge page pool.  These are called "persistent"
> > > > +huge pages.  A user with root privileges can dynamically allocate more or
> > > > +free some persistent huge pages by increasing or decreasing the value of
> > > > +'nr_hugepages'.
> > > > +
> > > 
> > > So they're not necessarily "preallocated" then if they're already in use.
> > 
> > I don't see what in the text you're referring to"  "preallocated" vs
> > "already in use" ???
> > 
> 
> Your new line, "/proc/sys/vm/nr_hugepages indicates the current number of 
> huge pages preallocated in the kernel's huge page pool" doesn't seem 
> correct since pages are not "pre"-allocated if they are used by an 
> application.  Preallocation is only when pages are allocated for a 
> performance optimization in a later hotpath (such as in a slab allocator) 
> or when the allocation cannot be done later in a non-blocking context.  If 
> you were to remove "pre" from that line it would be clear.
> 
> > > Not sure if you need to spell out that they're called "huge page allowed 
> > > nodes," isn't that an implementation detail?  The way Paul Jackson used to 
> > > describe nodes_allowed is "set of allowable nodes," and I can't think of a 
> > > better phrase.  That's also how the cpuset documentation describes them.
> > 
> > I wanted to refer to "huge pages allowed nodes" to differentiate from,
> > e.g., cpusets mems_allowed"--i.e., I wanted the "huge pages" qualifier.
> > I suppose I could introduce the phrase you suggest:  "set of allowable
> > nodes" and emphasize that in this doc, it only refers to nodes from
> > which persistent huge pages will be allocated.
> > 
> 
> It's a different story if you want to use the phrase "allowed nodes" 
> throughout this document to mean "the set of allowed nodes from which to 
> allocate hugepages depending on the allocating task's mempolicy," but I 
> didn't see any future reference to that phrase in your changes anyway.
> 
> > I understand.  However, I do think it's useful to support both a mask
> > [and Mel prefers it be based on mempolicy] and per node attributes.  On
> > some of our platforms, we do want explicit control over the placement of
> > huge pages--e.g., for a data base shared area or such.  So, we can say,
> > "I need <N> huge pages, and I want them on nodes 1, 3, 4 and 5", and
> > then, assuming we start with no huge pages allocated [free them all if
> > this is not the case]:
> > 
> > 	numactl -m 1,3-5 hugeadm --pool-pages-min 2M:<N>
> > 
> > Later, if I decide that maybe I want to adjust the number on node 1, I
> > can:
> > 
> > 	numactl -m 1 --pool-pages-min 2M:{+|-}<count>
> > 
> > or:
> > 
> > 	echo <new-value> >/sys/devices/system/node/node1/hugepages/hugepages-2048KB/nr_hugepages
> > 
> > [Of course, I'd probably do this in a script to avoid all that typing :)]
> > 
> 
> Yes, but the caveat I'm pointing out (and is really clearly described in 
> your documentation changes here) is that existing applications, shell 
> scripts, job schedulers, whatever, which currently free all system 
> hugepages (or do so at a consistent interval down to the surplus 
> value to reclaim memory) will now leak disjoint pages since the freeing is 
> now governed by its mempolicy. 

While this is a possibility, it makes little sense to assume that behaviour. To
be really bitten by the change, the policy used to allocate huge pages needs
to be different than the policy used to free them. This would be a bit
screwy as it would imply the job scheduler allocated pages that would
then be unusable by the job if policies were being obeyed which makes
very little sense.

> If the benefits of doing this 
> significantly outweigh that potential for userspace breakage, I have no 
> objection to it.  I just can't say for certain that it is.
> 

An application depending on memory policies to be ignored is pretty broken
to begin with.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Date: Tue, 8 Sep 2009 21:04:51 +0100
Message-ID: <20090908200451.GA6481@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Tue, Sep 08, 2009 at 12:51:48PM -0700, David Rientjes wrote:
> On Tue, 8 Sep 2009, Mel Gorman wrote:
> 
> > > Yes, but the caveat I'm pointing out (and is really clearly described in 
> > > your documentation changes here) is that existing applications, shell 
> > > scripts, job schedulers, whatever, which currently free all system 
> > > hugepages (or do so at a consistent interval down to the surplus 
> > > value to reclaim memory) will now leak disjoint pages since the freeing is 
> > > now governed by its mempolicy. 
> > 
> > While this is a possibility, it makes little sense to assume that behaviour. To
> > be really bitten by the change, the policy used to allocate huge pages needs
> > to be different than the policy used to free them. This would be a bit
> > screwy as it would imply the job scheduler allocated pages that would
> > then be unusable by the job if policies were being obeyed which makes
> > very little sense.
> > 
> 
> Au contraire, the hugepages= kernel parameter is not restricted to any 
> mempolicy.
> 

I'm not seeing how it would be considered symmetric to compare allocation
at a boot-time parameter with freeing happening at run-time within a mempolicy.
It's more plausible to me that such a scenario will having the freeing
thread either with no policy or the ability to run with no policy
applied.

> > > If the benefits of doing this 
> > > significantly outweigh that potential for userspace breakage, I have no 
> > > objection to it.  I just can't say for certain that it is.
> > > 
> > 
> > An application depending on memory policies to be ignored is pretty broken
> > to begin with.
> > 
> 
> Theoretically, yes, but not in practice.  /proc/sys/vm/nr_hugepages has 
> always allocated and freed with disregard to current's mempolicy prior to 
> this patchset and it wouldn't be "broken" for an application to assume 
> that it will continue to do so. 

I don't think we're going to agree on this one. I find it very unlikely
that the process doing the allocation and freeing is going to have
different memory policies.

> More broken is assuming that such an 
> application should have been written to change its mempolicy to include 
> all nodes that have hugepages prior to freeing because someday the kernel 
> would change to do mempolicy-restricted hugepage freeing.
> 

It wouldn't have to be rewritten. At very worst, rearranged at startup
to have the same policy when allocating and freeing.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Date: Tue, 8 Sep 2009 22:41:10 +0100
Message-ID: <20090908214109.GB6481@csn.ul.ie>
References: <20090828160314.11080.18541.sendpatchset@localhost.localdomain> <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Tue, Sep 08, 2009 at 01:18:01PM -0700, David Rientjes wrote:
> On Tue, 8 Sep 2009, Mel Gorman wrote:
> 
> > > Au contraire, the hugepages= kernel parameter is not restricted to any 
> > > mempolicy.
> > > 
> > 
> > I'm not seeing how it would be considered symmetric to compare allocation
> > at a boot-time parameter with freeing happening at run-time within a mempolicy.
> > It's more plausible to me that such a scenario will having the freeing
> > thread either with no policy or the ability to run with no policy
> > applied.
> > 
> 
> Imagine a cluster of machines that are all treated equally to serve a 
> variety of different production jobs.  One of those production jobs 
> requires a very high percentage of hugepages.  In fact, its performance 
> gain is directly proportional to the number of hugepages allocated.
> 
> It is quite plausible for all machines to be booted with hugepages= to 
> achieve the maximum number of hugepages that those machines may support.  
> Depending on what jobs they will serve, however, those hugepages may 
> immediately be freed (or a subset, depending on other smaller jobs that 
> may want them.)  If the job scheduler is bound to a mempolicy which does 
> not include all nodes with memory, those hugepages are now leaked. 

Why is a job scheduler that is expecting to affect memory on a global
basis running inside a mempolicy that restricts it to a subset of nodes?
It seems inconsistent that an isolated job starting could affect the global
state potentially affecting other jobs starting up.

In addition, if it is the case that the jobs performance is directly
proportional to the number of hugepages it gets access to, why is it starting
up with access to only a subset of the available hugepages? Why is it not
being setup to being the first job to start on a freshly booting machine,
starting on the subset of nodes allowed and requesting the maximum number
of hugepages it needs such that it achieves maximum performance? With the
memory policy approach, it's very straight-forward to do this because all
it has to do is write to nr_hugepages when it starts-up.

> That 
> was not the behavior over the past three or four years until this 
> patchset.
> 

While this is true, I know people have also been bitten by the expectation
that writing to nr_hugepages would obey a memory policy and were surprised
when it didn't happen and sent me whinging emails. It also appeared obvious
to me that it's how the interface should behave even if it wasn't doing it
in practice. Once nr_hugepages obeys memory policies, it's fairly convenient
to size the number of pages on a subset of nodes using numactl - a tool that
people would generally expect to be used when operating on nodes. Hence the
example usage being

numactl -m x,y,z hugeadm --pool-pages-min $PAGESIZE:$NUMPAGES

> That example is not dealing in hypotheticals or assumptions on how people 
> use hugepages, it's based on reality.  As I said previously, I don't 
> necessarily have an objection to that if it can be shown that the 
> advantages significantly outweigh the disadvantages.  I'm not sure I see 
> the advantage in being implict vs. explicit, however. 

The advantage is that with memory policies on nr_hugepages, it's very
convenient to allocate pages within a subset of nodes without worrying about
where exactly those huge pages are being allocated from. It will allocate
them on a round-robin basis allocating more pages on one node over another
if fragmentation requires it rather than shifting the burden to a userspace
application figuring out what nodes might succeed an allocation or shifting
the burden onto the system administrator. It's likely that writing to the
global nr_hugepages within a mempolicy will end up with a more sensible
result than a userspace application dealing with the individual node-specific
nr_hugepages files.

To do the same with the explicit interface, a userspace application
or administrator would have to keep reading the existing nr_hugepages,
writing existing_nr_hugepages+1 to each node in the allowed set, re-reading
to check for allocating failure and round-robining by hand.  This seems
awkward-for-the-sake-of-being-awkward when the kernel is already prefectly
aware of how to round-robin allocate the requested number of nodes allocating
more on one node if necessary.

> Mempolicy 
> allocation and freeing is now _implicit_ because its restricted to 
> current's mempolicy when it wasn't before, yet node-targeted hugepage 
> allocation and freeing is _explicit_ because it's a new interface and on 
> the same granularity.
> 

Arguably because the application was restricted by a memory policy, it
should not be able to operating outside of that policy and be forbidden
from writing to per-node-nr_hugepages outside the allowed set.  However,
that would appear awkward for the sake of it.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Date: Wed, 9 Sep 2009 09:16:31 +0100
Message-ID: <20090909081631.GB24614@csn.ul.ie>
References: <20090828160351.11080.21379.sendpatchset@localhost.localdomain> <alpine.DEB.1.00.0909031254380.26408@chino.kir.corp.google.com> <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Tue, Sep 08, 2009 at 03:54:40PM -0700, David Rientjes wrote:
> On Tue, 8 Sep 2009, Mel Gorman wrote:
> 
> > Why is a job scheduler that is expecting to affect memory on a global
> > basis running inside a mempolicy that restricts it to a subset of nodes?
> 
> Because hugepage allocation and freeing has always been on a global basis, 
> there was no previous restriction.
> 

And to beat a dead horse, it does make sense that an application
allocating hugepages obey memory policies. It does with dynamic hugepage
resizing for example. It should have been done years ago and
unfortunately wasn't but it's not the first time that the behaviour of
hugepages differed from the core VM.

> > In addition, if it is the case that the jobs performance is directly
> > proportional to the number of hugepages it gets access to, why is it starting
> > up with access to only a subset of the available hugepages?
> 
> It's not, that particular job is allocated the entire machine other than 
> the job scheduler. The point is that the machine pool treats each machine 
> equally so while they are all booted with hugepages=<large number>, 
> machines that don't serve this application immediately free them.  If 
> hugepages cannot be dynamically allocated up to a certain threshold that 
> the application requires, a reboot is necessary if no other machines are 
> available.
> 
> Since the only way to achieve the absolute maximum number of hugepages 
> possible on a machine is through the command line, it's completely 
> reasonable to use it on every boot and then subsequently free them when 
> they're unnecessary.
> 

But less reasonable that an application within a memory policy be able
to affect memory on a global basis. Why not let it break cpusets or
something else as well?

> > Why is it not
> > being setup to being the first job to start on a freshly booting machine,
> > starting on the subset of nodes allowed and requesting the maximum number
> > of hugepages it needs such that it achieves maximum performance? With the
> > memory policy approach, it's very straight-forward to do this because all
> > it has to do is write to nr_hugepages when it starts-up.
> > 
> 
> The job scheduler will always be the first job to start on the machine and 
> it may have a mempolicy of its own.  When it attempts to free all 
> hugepages allocated by the command line, it will then leak pages because 
> of these changes.
> 
> Arguing that applications should always dynamically allocate their 
> hugepages on their own subset of nodes when they are started is wishful 
> thinking: it's much easier to allocate as many as possible on the command 
> line and then free unnecessary hugepages than allocate on the mempolicy's 
> nodes for the maximal number of hugepages.
> 

Only in your particular case where you're willing to reboot the machine to
satisfy a jobs hugepage requirement. This is not always the situation. On
shared-machines, there can be many jobs running, each with different hugepage
requirements. The objective of things like anti-fragmentation, lumpy reclaim
and the like was to allow these sort of jobs to allocate the pages they
need at run-time. In the event these jobs are running on a subset of nodes,
it's of benefit to have nr_hugepages obey memory policies or else userspace
or the administrator has to try a number of different tricks to get the
hugepages they need on the nodes they want.

> > > That 
> > > was not the behavior over the past three or four years until this 
> > > patchset.
> > > 
> > 
> > While this is true, I know people have also been bitten by the expectation
> > that writing to nr_hugepages would obey a memory policy and were surprised
> > when it didn't happen and sent me whinging emails.
> 
> Ok, but I doubt the inverse is true: people probably haven't emailed you 
> letting you know that they've coded their application for hugepage 
> allocations based on how the kernel has implemented it for years, so 
> there's no context. 

They didn't code their application specifically to this case. What happened
is that their jobs needed to run on a subset of nodes and they wanted the
hugepages only available on those nodes. They wrote the value under a memory
policy to nr_hugepages and were suprised when that didn't work. cpusets were
not an obvious choice.

> That's the population that I'm worried about (and is 
> also solved by node-targeted hugepage allocation, btw).
> 

I disagree because it pushes the burden of interleaving to the userspace
application or the administrator, something the kernel can and is able
to deal with.

>  [ Such users who have emailed you could always use cpusets for the
>    desired effect, it's not like there isn't a solution. ]
>  

Which is very convulated. numactl is the expected administrative interface
to restrict allocations on a set of nodes, not cpusets.

> > It also appeared obvious
> > to me that it's how the interface should behave even if it wasn't doing it
> > in practice. Once nr_hugepages obeys memory policies, it's fairly convenient
> > to size the number of pages on a subset of nodes using numactl - a tool that
> > people would generally expect to be used when operating on nodes. Hence the
> > example usage being
> > 
> > numactl -m x,y,z hugeadm --pool-pages-min $PAGESIZE:$NUMPAGES
> > 
> 
> We need a new mempolicy flag, then, such as MPOL_F_HUGEPAGES to constrain 
> hugepage allocation and freeing via the global tunable to such a 
> mempolicy.
> 

This would be somewhat inconsistent. When dynamic hugepage pool resizing
is enabled, the application obeys the memory policy that is in place.
Your suggested policy would only apply when nr_hugepages is being
written to.

It would also appear as duplicated and redundant functionality to numactl
because it would have --interleave meaning interleaving and --hugepages
meaning interleave but only when nr_hugepages is being written to.

> > The advantage is that with memory policies on nr_hugepages, it's very
> > convenient to allocate pages within a subset of nodes without worrying about
> > where exactly those huge pages are being allocated from. It will allocate
> > them on a round-robin basis allocating more pages on one node over another
> > if fragmentation requires it rather than shifting the burden to a userspace
> > application figuring out what nodes might succeed an allocation or shifting
> > the burden onto the system administrator.
> 
> That "burden" is usually for good reason: if my MPOL_INTERLEAVE policy 
> gets hugepages that are relatively unbalanced across a set of nodes that I 
> arbitrarily picked, my interleave it's going to be nearly as optimized 
> compared to what userspace can allocate with the node-targeted approach: 
> allocate [desired nr of hugepages] / [nr nodes in policy] hugepages via 
> /sys/devices/system/node/node*/nr_hugepages, and construct a policy out of 
> the nodes that give a true interleave.

Except that knowledge and awareness of having to do this is pushed out
to userspace and the system administrator, when again it's something
the kernel can trivially do on their behalf.

> That's not a trivial performance 
> gain and can rarely be dismissed by simply picking an arbitrary set.
> 
> > It's likely that writing to the
> > global nr_hugepages within a mempolicy will end up with a more sensible
> > result than a userspace application dealing with the individual node-specific
> > nr_hugepages files.
> > 
> 
> Disagree for the interleave example above without complex userspace logic 
> to determine how successful hugepage allocation will be based on 
> fragmentation.
> 

It can read the value back for nr_hugepages to see was the total number
of allocation successful. hugeadm does this for example and warns when the
desired number of pages were not allocated (or not freed for that example). It
would not detect if the memory allocations were imbalanced without taking
further steps but it would depend on whether being evenly interleaved was
more important than having the maximum number of hugepages.

> > To do the same with the explicit interface, a userspace application
> > or administrator would have to keep reading the existing nr_hugepages,
> > writing existing_nr_hugepages+1 to each node in the allowed set, re-reading
> > to check for allocating failure and round-robining by hand.  This seems
> > awkward-for-the-sake-of-being-awkward when the kernel is already prefectly
> > aware of how to round-robin allocate the requested number of nodes allocating
> > more on one node if necessary.
> > 
> 
> No need for an iteration, simply allocate the ratio I specified above on 
> each node and then construct a mempolicy from those nodes based on actual 
> results instead of arbitrarily.
> 

They would still need to read back the values, determine if the full
allocation was successful and if not, figure out where it failed and
recalculate. 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Date: Thu, 10 Sep 2009 13:26:42 +0100
Message-ID: <20090910122641.GA31153@csn.ul.ie>
References: <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Wed, Sep 09, 2009 at 01:44:28PM -0700, David Rientjes wrote:
> On Wed, 9 Sep 2009, Mel Gorman wrote:
> 
> > And to beat a dead horse, it does make sense that an application
> > allocating hugepages obey memory policies. It does with dynamic hugepage
> > resizing for example. It should have been done years ago and
> > unfortunately wasn't but it's not the first time that the behaviour of
> > hugepages differed from the core VM.
> > 
> 
> I agree completely, I'm certainly not defending the current implementation 
> as a sound design and I too would have preferred that it have done the 
> same as Lee's patchset from the very beginning.  The issue I'm raising is 
> that while we both agree the current behavior is suboptimal and confusing, 
> it is the long-standing kernel behavior.  There are applications out there 
> that are written to allocate and free hugepages and now changing the pool 
> from which they can allocate or free to could be problematic.
> 

While I doubt there are many, the counter-example of one is not
something I can wish or wave away.

> I'm personally fine with the breakage since I'm aware of this discussion 
> and can easily fix it in userspace.  I'm more concerned about others 
> leaking hugepages or having their boot scripts break because they are 
> allocating far fewer hugepages than before. 

I just find it very improbably that system-wide maintenance or boot-up
processes are running within restricted environments that then expect to
have system-wide capabilities but it wouldn't be the first time something
unusual was implemented.

> The documentation 
> (Documentation/vm/hugetlbpage.txt) has always said 
> /proc/sys/vm/nr_hugepaegs affects hugepages on a system level and now that 
> it's changed, I think it should be done explicitly with a new flag than 
> implicitly.
> 
> Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
> and only using the new behavior when this is set would be inconsistent or 
> inadvisible?

I already explained this. The interface in numactl would look weird. There
would be an --interleave switch and a --hugepages-interleave that only
applies to nr_hugepages. The smarts could be in hugeadm to apply the mask
when --pool-pages-min is specified but that wouldn't help scripts that are
still using echo.

> Since this is a new behavior that will differ from the 
> long-standing default, it seems like it warrants a new mempolicy flag to 
> avoid all userspace breakage and make hugepage allocation and freeing with 
> an underlying mempolicy explicit.
> 
> This would address your audience that have been (privately) emailing you 
> while confused about why the hugepages being allocated from a global 
> tunable wouldn't be confined to their mempolicy.
> 

I hate to have to do this, but how about nr_hugepages which acts
system-wide as it did traditionally and nr_hugepages_mempolicy that obeys
policies? Something like the following untested patch. It would be fairly
trivial for me to implement a --obey-mempolicies switch for hugeadm which
works in conjunction with --pool--pages-min and less likely to cause confusion
than --hugepages-interleave in numactl.

Sorry the patch is untested. I can't hold of a NUMA machine at the moment
and fake NUMA support sucks far worse than I expected it to.

==== BEGIN PATCH ====

[PATCH] Optionally use a memory policy when tuning the size of the static hugepage pool

Patch "derive huge pages nodes allowed from task mempolicy" brought
huge page support more in line with the core VM in that tuning the size
of the static huge page pool would obey memory policies. Using this,
administrators could interleave allocation of huge pages from a subset
of nodes. This is consistent with how dynamic hugepage pool resizing
works and how hugepages get allocated to applications at run-time.

However, it was pointed out that scripts may exist that depend on being
able to drain all hugepages via /proc/sys/vm/nr_hugepages from processes
that are running within a memory policy. This patch adds
/proc/sys/vm/nr_hugepages_mempolicy which when written to will obey
memory policies. /proc/sys/vm/nr_hugepages continues then to be a
system-wide tunable regardless of memory policy.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
--- 
 include/linux/hugetlb.h |    1 +
 kernel/sysctl.c         |   11 +++++++++++
 mm/hugetlb.c            |   35 ++++++++++++++++++++++++++++++++---
 3 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index fcb1677..fc3a659 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -21,6 +21,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
 
 void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
 int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
+int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
 int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
 int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
 int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8bac3f5..0637655 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1171,6 +1171,17 @@ static struct ctl_table vm_table[] = {
 		.extra1		= (void *)&hugetlb_zero,
 		.extra2		= (void *)&hugetlb_infinity,
 	 },
+#ifdef CONFIG_NUMA
+	 {
+		.procname	= "nr_hugepages_mempolicy",
+		.data		= NULL,
+		.maxlen		= sizeof(unsigned long),
+		.mode		= 0644,
+		.proc_handler	= &hugetlb_mempolicy_sysctl_handler,
+		.extra1		= (void *)&hugetlb_zero,
+		.extra2		= (void *)&hugetlb_infinity,
+	 },
+#endif
 	 {
 		.ctl_name	= VM_HUGETLB_GROUP,
 		.procname	= "hugetlb_shm_group",
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 83decd6..68abef0 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
 	return ret;
 }
 
+#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
 #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
 static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
 								int nid)
@@ -1254,9 +1255,14 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
 	if (h->order >= MAX_ORDER)
 		return h->max_huge_pages;
 
-	if (nid == NUMA_NO_NODE) {
+	switch (nid) {
+	case NUMA_NO_NODE_OBEY_MEMPOLICY:
 		nodes_allowed = alloc_nodemask_of_mempolicy();
-	} else {
+		break;
+	case NUMA_NO_NODE:
+		nodes_allowed = NULL;
+		break;
+	default:
 		/*
 		 * incoming 'count' is for node 'nid' only, so
 		 * adjust count to global, but restrict alloc/free
@@ -1265,7 +1271,7 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
 		count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
 		nodes_allowed = alloc_nodemask_of_node(nid);
 	}
-	if (!nodes_allowed) {
+	if (!nodes_allowed && nid != NUMA_NO_NODE) {
 		printk(KERN_WARNING "%s unable to allocate nodes allowed mask "
 			"for huge page allocation.  Falling back to default.\n",
 			current->comm);
@@ -1796,6 +1802,29 @@ int hugetlb_sysctl_handler(struct ctl_table *table, int write,
 	return 0;
 }
 
+#ifdef CONFIG_NUMA
+int hugetlb_mempolicy_sysctl_handler(struct ctl_table *table, int write,
+			   void __user *buffer,
+			   size_t *length, loff_t *ppos)
+{
+	struct hstate *h = &default_hstate;
+	unsigned long tmp;
+
+	if (!write)
+		tmp = h->max_huge_pages;
+
+	table->data = &tmp;
+	table->maxlen = sizeof(unsigned long);
+	proc_doulongvec_minmax(table, write, buffer, length, ppos);
+
+	if (write)
+		h->max_huge_pages = set_max_huge_pages(h, tmp,
+					NUMA_NO_NODE_OBEY_MEMPOLICY);
+
+	return 0;
+}
+#endif /* CONFIG_NUMA */
+
 int hugetlb_treat_movable_handler(struct ctl_table *table, int write,
 			void __user *buffer,
 			size_t *length, loff_t *ppos)

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Fri, 11 Sep 2009 15:27:30 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com>
References: <1252012158.6029.215.camel@useless.americas.hpqcorp.net> <alpine.DEB.1.00.0909031416310.1459@chino.kir.corp.google.com> <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie>
 <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com>
 <20090910122641.GA31153@csn.ul.ie>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252708058; bh=/6q+tpAEwZdG9jifCoFRh0gd7Lw=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=uYXBsVWCdiKSJTFKvKSFDVHgZAo3DjZ
	YAfkA/K+H+Zgeb8SyUuO8F+ss/c+uqc8oxj0kebVUwRo4fiq13VZHew==
In-Reply-To: <20090910122641.GA31153@csn.ul.ie>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Thu, 10 Sep 2009, Mel Gorman wrote:

> > Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
> > and only using the new behavior when this is set would be inconsistent or 
> > inadvisible?
> 
> I already explained this. The interface in numactl would look weird. There
> would be an --interleave switch and a --hugepages-interleave that only
> applies to nr_hugepages. The smarts could be in hugeadm to apply the mask
> when --pool-pages-min is specified but that wouldn't help scripts that are
> still using echo.
> 

I don't think we need to address the scripts that are currently using echo 
since they're (hopefully) written to the kernel implementation, i.e. no 
mempolicy restriction on writing to nr_hugepages.

> I hate to have to do this, but how about nr_hugepages which acts
> system-wide as it did traditionally and nr_hugepages_mempolicy that obeys
> policies? Something like the following untested patch. It would be fairly
> trivial for me to implement a --obey-mempolicies switch for hugeadm which
> works in conjunction with --pool--pages-min and less likely to cause confusion
> than --hugepages-interleave in numactl.
> 

I like it.

> Sorry the patch is untested. I can't hold of a NUMA machine at the moment
> and fake NUMA support sucks far worse than I expected it to.
> 

Hmm, I rewrote most of fake NUMA a couple years ago.  What problems are 
you having with it?

> ==== BEGIN PATCH ====
> 
> [PATCH] Optionally use a memory policy when tuning the size of the static hugepage pool
> 
> Patch "derive huge pages nodes allowed from task mempolicy" brought
> huge page support more in line with the core VM in that tuning the size
> of the static huge page pool would obey memory policies. Using this,
> administrators could interleave allocation of huge pages from a subset
> of nodes. This is consistent with how dynamic hugepage pool resizing
> works and how hugepages get allocated to applications at run-time.
> 
> However, it was pointed out that scripts may exist that depend on being
> able to drain all hugepages via /proc/sys/vm/nr_hugepages from processes
> that are running within a memory policy. This patch adds
> /proc/sys/vm/nr_hugepages_mempolicy which when written to will obey
> memory policies. /proc/sys/vm/nr_hugepages continues then to be a
> system-wide tunable regardless of memory policy.
> 
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> --- 
>  include/linux/hugetlb.h |    1 +
>  kernel/sysctl.c         |   11 +++++++++++
>  mm/hugetlb.c            |   35 ++++++++++++++++++++++++++++++++---
>  3 files changed, 44 insertions(+), 3 deletions(-)
> 

It'll need an update to Documentation/vm/hugetlb.txt, but this can 
probably be done in one of Lee's patches that edits the same file when he 
reposts.

> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index fcb1677..fc3a659 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -21,6 +21,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
>  
>  void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
>  int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> +int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
>  int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
>  int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
>  int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 8bac3f5..0637655 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1171,6 +1171,17 @@ static struct ctl_table vm_table[] = {
>  		.extra1		= (void *)&hugetlb_zero,
>  		.extra2		= (void *)&hugetlb_infinity,
>  	 },
> +#ifdef CONFIG_NUMA
> +	 {
> +		.procname	= "nr_hugepages_mempolicy",
> +		.data		= NULL,
> +		.maxlen		= sizeof(unsigned long),
> +		.mode		= 0644,
> +		.proc_handler	= &hugetlb_mempolicy_sysctl_handler,
> +		.extra1		= (void *)&hugetlb_zero,
> +		.extra2		= (void *)&hugetlb_infinity,
> +	 },
> +#endif
>  	 {
>  		.ctl_name	= VM_HUGETLB_GROUP,
>  		.procname	= "hugetlb_shm_group",
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 83decd6..68abef0 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
>  	return ret;
>  }
>  
> +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
>  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
>  static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
>  								int nid)

I think it would be possible to avoid adding NUMA_NO_NODE_OBEY_MEMPOLICY 
if the nodemask was allocated in the sysctl handler instead and passing it 
into set_max_huge_pages() instead of a nid.  Lee, what do you think?


Other than that, I like this approach because it avoids the potential for 
userspace breakage while adding the new feature in way that avoids 
confusion.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
 mempolicy based management.
Date: Mon, 14 Sep 2009 10:15:48 -0400
Message-ID: <1252937748.17132.111.camel@useless.americas.hpqcorp.net>
References: <20090908104409.GB28127@csn.ul.ie>
	 <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com>
	 <20090908200451.GA6481@csn.ul.ie>
	 <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com>
	 <20090908214109.GB6481@csn.ul.ie>
	 <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com>
	 <20090909081631.GB24614@csn.ul.ie>
	 <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com>
	 <20090910122641.GA31153@csn.ul.ie>
	 <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com>
	 <20090914133329.GC11778@csn.ul.ie>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-numa-owner@vger.kernel.org>
In-Reply-To: <20090914133329.GC11778@csn.ul.ie>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Mel Gorman <mel@csn.ul.ie>
Cc: David Rientjes <rientjes@google.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Mon, 2009-09-14 at 14:33 +0100, Mel Gorman wrote:
> On Fri, Sep 11, 2009 at 03:27:30PM -0700, David Rientjes wrote:
> > On Thu, 10 Sep 2009, Mel Gorman wrote:
> > 
> > > > Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
> > > > and only using the new behavior when this is set would be inconsistent or 
> > > > inadvisible?
> > > 
> > > I already explained this. The interface in numactl would look weird. There
> > > would be an --interleave switch and a --hugepages-interleave that only
> > > applies to nr_hugepages. The smarts could be in hugeadm to apply the mask
> > > when --pool-pages-min is specified but that wouldn't help scripts that are
> > > still using echo.
> > > 
> > 
> > I don't think we need to address the scripts that are currently using echo 
> > since they're (hopefully) written to the kernel implementation, i.e. no 
> > mempolicy restriction on writing to nr_hugepages.
> > 
> 
> Ok.
> 
> > > I hate to have to do this, but how about nr_hugepages which acts
> > > system-wide as it did traditionally and nr_hugepages_mempolicy that obeys
> > > policies? Something like the following untested patch. It would be fairly
> > > trivial for me to implement a --obey-mempolicies switch for hugeadm which
> > > works in conjunction with --pool--pages-min and less likely to cause confusion
> > > than --hugepages-interleave in numactl.
> > > 
> > 
> > I like it.
> > 
> 
> Ok, when I get this tested, I'll sent it as a follow-on patch to Lee's
> for proper incorporation.
> 
> > > Sorry the patch is untested. I can't hold of a NUMA machine at the moment
> > > and fake NUMA support sucks far worse than I expected it to.
> > > 
> > 
> > Hmm, I rewrote most of fake NUMA a couple years ago.  What problems are 
> > you having with it?
> > 
> 
> On PPC64, the parameters behave differently. I couldn't convince it to
> create more than one NUMA node. On x86-64, the NUMA nodes appeared to
> exist and would be visible on /proc/buddyinfo for example but the sysfs
> directories for the fake nodes were not created so nr_hugepages couldn't
> be examined on a per-node basis for example.
> 
> > > ==== BEGIN PATCH ====
> > > 
> > > [PATCH] Optionally use a memory policy when tuning the size of the static hugepage pool
> > > 
> > > Patch "derive huge pages nodes allowed from task mempolicy" brought
> > > huge page support more in line with the core VM in that tuning the size
> > > of the static huge page pool would obey memory policies. Using this,
> > > administrators could interleave allocation of huge pages from a subset
> > > of nodes. This is consistent with how dynamic hugepage pool resizing
> > > works and how hugepages get allocated to applications at run-time.
> > > 
> > > However, it was pointed out that scripts may exist that depend on being
> > > able to drain all hugepages via /proc/sys/vm/nr_hugepages from processes
> > > that are running within a memory policy. This patch adds
> > > /proc/sys/vm/nr_hugepages_mempolicy which when written to will obey
> > > memory policies. /proc/sys/vm/nr_hugepages continues then to be a
> > > system-wide tunable regardless of memory policy.
> > > 
> > > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > > --- 
> > >  include/linux/hugetlb.h |    1 +
> > >  kernel/sysctl.c         |   11 +++++++++++
> > >  mm/hugetlb.c            |   35 ++++++++++++++++++++++++++++++++---
> > >  3 files changed, 44 insertions(+), 3 deletions(-)
> > > 
> > 
> > It'll need an update to Documentation/vm/hugetlb.txt, but this can 
> > probably be done in one of Lee's patches that edits the same file when he 
> > reposts.
> > 
> 
> Agreed.

So, I'm respinning V7 today.  Shall I add this in as a separate patch?

Also, see below:


> 
> > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > > index fcb1677..fc3a659 100644
> > > --- a/include/linux/hugetlb.h
> > > +++ b/include/linux/hugetlb.h
> > > @@ -21,6 +21,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
> > >  
> > >  void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
> > >  int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > +int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > >  int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > >  int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > >  int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
> > > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > > index 8bac3f5..0637655 100644
> > > --- a/kernel/sysctl.c
> > > +++ b/kernel/sysctl.c
> > > @@ -1171,6 +1171,17 @@ static struct ctl_table vm_table[] = {
> > >  		.extra1		= (void *)&hugetlb_zero,
> > >  		.extra2		= (void *)&hugetlb_infinity,
> > >  	 },
> > > +#ifdef CONFIG_NUMA
> > > +	 {
> > > +		.procname	= "nr_hugepages_mempolicy",
> > > +		.data		= NULL,
> > > +		.maxlen		= sizeof(unsigned long),
> > > +		.mode		= 0644,
> > > +		.proc_handler	= &hugetlb_mempolicy_sysctl_handler,
> > > +		.extra1		= (void *)&hugetlb_zero,
> > > +		.extra2		= (void *)&hugetlb_infinity,
> > > +	 },
> > > +#endif
> > >  	 {
> > >  		.ctl_name	= VM_HUGETLB_GROUP,
> > >  		.procname	= "hugetlb_shm_group",
> > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > index 83decd6..68abef0 100644
> > > --- a/mm/hugetlb.c
> > > +++ b/mm/hugetlb.c
> > > @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
> > >  	return ret;
> > >  }
> > >  
> > > +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)

How about defining NUMA_NO_NODE_OBEY_MEMPOLICY as (NUMA_NO_NODE - 1)
just to ensure that it's different.  Not sure it's worth an enum at this
point.  NUMA_NO_NODE_OBEY_MEMPOLICY is private to hugetlb at this time.

> > >  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> > >  static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> > >  								int nid)
> > 
> > I think it would be possible to avoid adding NUMA_NO_NODE_OBEY_MEMPOLICY 
> > if the nodemask was allocated in the sysctl handler instead and passing it 
> > into set_max_huge_pages() instead of a nid.  Lee, what do you think?
> > 
> > Other than that, I like this approach because it avoids the potential for 
> > userspace breakage while adding the new feature in way that avoids 
> > confusion.
> > 
> 
> Indeed. While the addition of another proc tunable sucks, it seems like
> the only available compromise.

And, I supposed we need to replicate this under the global sysfs
hstates?

Lee
> 


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Date: Mon, 14 Sep 2009 16:41:12 +0100
Message-ID: <20090914154112.GD11778@csn.ul.ie>
References: <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com> <20090914133329.GC11778@csn.ul.ie> <1252937748.17132.111.camel@useless.americas.hpqcorp.net>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <1252937748.17132.111.camel@useless.americas.hpqcorp.net>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: David Rientjes <rientjes@google.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Mon, Sep 14, 2009 at 10:15:48AM -0400, Lee Schermerhorn wrote:
> On Mon, 2009-09-14 at 14:33 +0100, Mel Gorman wrote:
> > On Fri, Sep 11, 2009 at 03:27:30PM -0700, David Rientjes wrote:
> > > On Thu, 10 Sep 2009, Mel Gorman wrote:
> > > 
> > > > > Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES, 
> > > > > and only using the new behavior when this is set would be inconsistent or 
> > > > > inadvisible?
> > > > 
> > > > I already explained this. The interface in numactl would look weird. There
> > > > would be an --interleave switch and a --hugepages-interleave that only
> > > > applies to nr_hugepages. The smarts could be in hugeadm to apply the mask
> > > > when --pool-pages-min is specified but that wouldn't help scripts that are
> > > > still using echo.
> > > > 
> > > 
> > > I don't think we need to address the scripts that are currently using echo 
> > > since they're (hopefully) written to the kernel implementation, i.e. no 
> > > mempolicy restriction on writing to nr_hugepages.
> > > 
> > 
> > Ok.
> > 
> > > > I hate to have to do this, but how about nr_hugepages which acts
> > > > system-wide as it did traditionally and nr_hugepages_mempolicy that obeys
> > > > policies? Something like the following untested patch. It would be fairly
> > > > trivial for me to implement a --obey-mempolicies switch for hugeadm which
> > > > works in conjunction with --pool--pages-min and less likely to cause confusion
> > > > than --hugepages-interleave in numactl.
> > > > 
> > > 
> > > I like it.
> > > 
> > 
> > Ok, when I get this tested, I'll sent it as a follow-on patch to Lee's
> > for proper incorporation.
> > 
> > > > Sorry the patch is untested. I can't hold of a NUMA machine at the moment
> > > > and fake NUMA support sucks far worse than I expected it to.
> > > > 
> > > 
> > > Hmm, I rewrote most of fake NUMA a couple years ago.  What problems are 
> > > you having with it?
> > > 
> > 
> > On PPC64, the parameters behave differently. I couldn't convince it to
> > create more than one NUMA node. On x86-64, the NUMA nodes appeared to
> > exist and would be visible on /proc/buddyinfo for example but the sysfs
> > directories for the fake nodes were not created so nr_hugepages couldn't
> > be examined on a per-node basis for example.
> > 
> > > > ==== BEGIN PATCH ====
> > > > 
> > > > [PATCH] Optionally use a memory policy when tuning the size of the static hugepage pool
> > > > 
> > > > Patch "derive huge pages nodes allowed from task mempolicy" brought
> > > > huge page support more in line with the core VM in that tuning the size
> > > > of the static huge page pool would obey memory policies. Using this,
> > > > administrators could interleave allocation of huge pages from a subset
> > > > of nodes. This is consistent with how dynamic hugepage pool resizing
> > > > works and how hugepages get allocated to applications at run-time.
> > > > 
> > > > However, it was pointed out that scripts may exist that depend on being
> > > > able to drain all hugepages via /proc/sys/vm/nr_hugepages from processes
> > > > that are running within a memory policy. This patch adds
> > > > /proc/sys/vm/nr_hugepages_mempolicy which when written to will obey
> > > > memory policies. /proc/sys/vm/nr_hugepages continues then to be a
> > > > system-wide tunable regardless of memory policy.
> > > > 
> > > > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > > > --- 
> > > >  include/linux/hugetlb.h |    1 +
> > > >  kernel/sysctl.c         |   11 +++++++++++
> > > >  mm/hugetlb.c            |   35 ++++++++++++++++++++++++++++++++---
> > > >  3 files changed, 44 insertions(+), 3 deletions(-)
> > > > 
> > > 
> > > It'll need an update to Documentation/vm/hugetlb.txt, but this can 
> > > probably be done in one of Lee's patches that edits the same file when he 
> > > reposts.
> > > 
> > 
> > Agreed.
> 
> So, I'm respinning V7 today.  Shall I add this in as a separate patch?
> 

If you can, it'd be great but I can also spin a patch on top of yours
and update the documentation accordingly if you prefer.

> Also, see below:
> 
> 
> > 
> > > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > > > index fcb1677..fc3a659 100644
> > > > --- a/include/linux/hugetlb.h
> > > > +++ b/include/linux/hugetlb.h
> > > > @@ -21,6 +21,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
> > > >  
> > > >  void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
> > > >  int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > > +int hugetlb_mempolicy_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > >  int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > >  int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);
> > > >  int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
> > > > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > > > index 8bac3f5..0637655 100644
> > > > --- a/kernel/sysctl.c
> > > > +++ b/kernel/sysctl.c
> > > > @@ -1171,6 +1171,17 @@ static struct ctl_table vm_table[] = {
> > > >  		.extra1		= (void *)&hugetlb_zero,
> > > >  		.extra2		= (void *)&hugetlb_infinity,
> > > >  	 },
> > > > +#ifdef CONFIG_NUMA
> > > > +	 {
> > > > +		.procname	= "nr_hugepages_mempolicy",
> > > > +		.data		= NULL,
> > > > +		.maxlen		= sizeof(unsigned long),
> > > > +		.mode		= 0644,
> > > > +		.proc_handler	= &hugetlb_mempolicy_sysctl_handler,
> > > > +		.extra1		= (void *)&hugetlb_zero,
> > > > +		.extra2		= (void *)&hugetlb_infinity,
> > > > +	 },
> > > > +#endif
> > > >  	 {
> > > >  		.ctl_name	= VM_HUGETLB_GROUP,
> > > >  		.procname	= "hugetlb_shm_group",
> > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > index 83decd6..68abef0 100644
> > > > --- a/mm/hugetlb.c
> > > > +++ b/mm/hugetlb.c
> > > > @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
> > > >  	return ret;
> > > >  }
> > > >  
> > > > +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
> 
> How about defining NUMA_NO_NODE_OBEY_MEMPOLICY as (NUMA_NO_NODE - 1)
> just to ensure that it's different.  Not sure it's worth an enum at this
> point.  NUMA_NO_NODE_OBEY_MEMPOLICY is private to hugetlb at this time.
> 

That seems reasonable.

> > > >  #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
> > > >  static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
> > > >  								int nid)
> > > 
> > > I think it would be possible to avoid adding NUMA_NO_NODE_OBEY_MEMPOLICY 
> > > if the nodemask was allocated in the sysctl handler instead and passing it 
> > > into set_max_huge_pages() instead of a nid.  Lee, what do you think?
> > > 
> > > Other than that, I like this approach because it avoids the potential for 
> > > userspace breakage while adding the new feature in way that avoids 
> > > confusion.
> > > 
> > 
> > Indeed. While the addition of another proc tunable sucks, it seems like
> > the only available compromise.
> 
> And, I supposed we need to replicate this under the global sysfs
> hstates?
> 

You're right, they would also be needed under /sys/kernel/mm/hugepages/*

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Mon, 14 Sep 2009 12:14:05 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909141213150.14000@chino.kir.corp.google.com>
References: <20090908104409.GB28127@csn.ul.ie> <alpine.DEB.1.00.0909081241530.10542@chino.kir.corp.google.com> <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie>
 <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com>
 <20090914133329.GC11778@csn.ul.ie>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252955651; bh=yrOQpTuLT5R1wryfKClXWk0p9Qg=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=Evht1dnEEOgsrbtGrrWbo7VntAS1qV7
	7YQPCKCaAVdtJ0/VAljj1fg86HfZlu2+EtLCRApA9Di/s8WKDRwDftQ==
In-Reply-To: <20090914133329.GC11778@csn.ul.ie>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Mon, 14 Sep 2009, Mel Gorman wrote:

> > Hmm, I rewrote most of fake NUMA a couple years ago.  What problems are 
> > you having with it?
> > 
> 
> On PPC64, the parameters behave differently. I couldn't convince it to
> create more than one NUMA node. On x86-64, the NUMA nodes appeared to
> exist and would be visible on /proc/buddyinfo for example but the sysfs
> directories for the fake nodes were not created so nr_hugepages couldn't
> be examined on a per-node basis for example.
> 

I don't know anything about the ppc64 fake NUMA, but the sysfs node 
directories should certainly be created on x86_64.  I'll look into it 
because that's certainly a bug.  Thanks.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for mempolicy
 based management.
Date: Mon, 14 Sep 2009 12:15:43 -0700 (PDT)
Message-ID: <alpine.DEB.1.00.0909141214170.14000@chino.kir.corp.google.com>
References: <20090908200451.GA6481@csn.ul.ie> <alpine.DEB.1.00.0909081307100.13678@chino.kir.corp.google.com> <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie>
 <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com> <20090914133329.GC11778@csn.ul.ie> <1252937748.17132.111.camel@useless.americas.hpqcorp.net>
 <20090914154112.GD11778@csn.ul.ie>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1252955749; bh=m20fw0tdh/gSGS+XCxvA1W5UKb8=;
	h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:
	 In-Reply-To:Message-ID:References:User-Agent:MIME-Version:
	 Content-Type:X-System-Of-Record; b=XHlsI1lp8rg9YBn7uiIHJI7UfFD7WcQ
	NmYEaGQA/Qd4NMeb8fCnfdZ3zD0/VMySKPlErg1gX6wlV+LtmlfZtOQ==
In-Reply-To: <20090914154112.GD11778@csn.ul.ie>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: Mel Gorman <mel@csn.ul.ie>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Mon, 14 Sep 2009, Mel Gorman wrote:

> > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > > index 83decd6..68abef0 100644
> > > > > --- a/mm/hugetlb.c
> > > > > +++ b/mm/hugetlb.c
> > > > > @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
> > > > >  	return ret;
> > > > >  }
> > > > >  
> > > > > +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
> > 
> > How about defining NUMA_NO_NODE_OBEY_MEMPOLICY as (NUMA_NO_NODE - 1)
> > just to ensure that it's different.  Not sure it's worth an enum at this
> > point.  NUMA_NO_NODE_OBEY_MEMPOLICY is private to hugetlb at this time.
> > 
> 
> That seems reasonable.
> 

If the nodemask allocation is moved to the sysctl handler and nodemask_t 
is passed into set_max_huge_pages() instead of nid, you don't need 
NUMA_NO_NODE_OBEY_MEMPOLICY at all, though.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH 6/6] hugetlb:  update hugetlb documentation for
	mempolicy based management.
Date: Tue, 15 Sep 2009 12:48:45 +0100
Message-ID: <20090915114844.GA31840@csn.ul.ie>
References: <20090908214109.GB6481@csn.ul.ie> <alpine.DEB.1.00.0909081527320.26432@chino.kir.corp.google.com> <20090909081631.GB24614@csn.ul.ie> <alpine.DEB.1.00.0909091335050.7764@chino.kir.corp.google.com> <20090910122641.GA31153@csn.ul.ie> <alpine.DEB.1.00.0909111507540.22083@chino.kir.corp.google.com> <20090914133329.GC11778@csn.ul.ie> <1252937748.17132.111.camel@useless.americas.hpqcorp.net> <20090914154112.GD11778@csn.ul.ie> <alpine.DEB.1.00.0909141214170.14000@chino.kir.corp.google.com>
Mime-Version: 1.0
Return-path: <linux-numa-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.00.0909141214170.14000@chino.kir.corp.google.com>
Sender: linux-numa-owner@vger.kernel.org
List-ID: <linux-numa.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Nishanth Aravamudan <nacc@us.ibm.com>, linux-numa@vger.kernel.org, Adam Litke <agl@us.ibm.com>, Andy Whitcroft <apw@canonical.com>, Eric Whitney <eric.whitney@hp.com>, Randy Dunlap <randy.dunlap@oracle.com>

On Mon, Sep 14, 2009 at 12:15:43PM -0700, David Rientjes wrote:
> On Mon, 14 Sep 2009, Mel Gorman wrote:
> 
> > > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > > > index 83decd6..68abef0 100644
> > > > > > --- a/mm/hugetlb.c
> > > > > > +++ b/mm/hugetlb.c
> > > > > > @@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
> > > > > >  	return ret;
> > > > > >  }
> > > > > >  
> > > > > > +#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)
> > > 
> > > How about defining NUMA_NO_NODE_OBEY_MEMPOLICY as (NUMA_NO_NODE - 1)
> > > just to ensure that it's different.  Not sure it's worth an enum at this
> > > point.  NUMA_NO_NODE_OBEY_MEMPOLICY is private to hugetlb at this time.
> > > 
> > 
> > That seems reasonable.
> > 
> 
> If the nodemask allocation is moved to the sysctl handler and nodemask_t 
> is passed into set_max_huge_pages() instead of nid, you don't need 
> NUMA_NO_NODE_OBEY_MEMPOLICY at all, though.
> 

Very likely. When V7 comes out, I'll spin a patch for that and see what
it looks like if Lee doesn't beat me to it.


-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab