hugetlb: V5 constrain allocation/free based on task mempolicy
Subsystems (7)
cover hugetlb: V5 constrain allocation/free based on task mempolicy
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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/6 hugetlb: rework hstate_next_node_* functions
[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.
mm/hugetlb.c | 70 +++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 45 insertions(+), 25 deletions(-)
mm/hugetlb.c +45 -25
@@ -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(structint 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 hsint 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(strucvoid *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 hsVM_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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 2/6 hugetlb: add nodemask arg to huge page alloc, free and surplus adjust fcns
In reply to Lee Schermerhorn[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.
mm/hugetlb.c | 121 +++++++++++++++++++++++++++++++++++------------------------ 1 file changed, 72 insertions(+), 49 deletions(-)
mm/hugetlb.c +72 -49
@@ -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(strucvoid *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 hsVM_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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 2/6] hugetlb: add nodemask arg to huge page alloc, free and surplus adjust fcns
Quoted 27 lines · Lee Schermerhorn
[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" ofhstate_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., usenode_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_hugepagesunder 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.
Quoted 2 lines
Reviewed-by Mel Gorman <[email protected]>Signed-off-by Lee Schermerhorn <[email protected]>
Still think the name `this_node_allowed()' is awkward, but I'm glad to see hstate_next_node_to_{alloc,free} is clean.
PATCH 3/6 hugetlb: derive huge pages nodes allowed from task mempolicy
In reply to Lee Schermerhorn[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.
include/linux/mempolicy.h | 3 ++ mm/hugetlb.c | 14 ++++++---- mm/mempolicy.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 73 insertions(+), 5 deletions(-)
mm/mempolicy.c +61 -0
@@ -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.
include/linux/mempolicy.h +3 -0
@@ -201,6 +201,7 @@ extern void mpol_fix_fork_child_flag(strextern 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_zonereturn 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)
mm/hugetlb.c +9 -5
@@ -1248,10 +1248,13 @@ static int adjust_pool_surplus(struct hsstatic 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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 3/6] hugetlb: derive huge pages nodes allowed from task mempolicy
Quoted 120 lines · Lee Schermerhorn
[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 inhuge_mpol_nodes_allowed().
+ added 'current->comm' to warning message inhuge_mpol_nodes_allowed().
+ addedVM_BUG_ON()assertion inhugetlb.cnext_node_allowed()to catch out of range node id.
+ add examples to patch descriptionV3: Factored this patch from V2 patch 2/3
V4: added back missing "
kfree(nodes_allowed)" inset_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_tpointer is produced. This will cause the hugetlb subsystem to usenode_online_mapas 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 adjustingnr_hugepages.
* For "bind" and "interleave" policy, the mempolicy's nodemask will be used.
* Other than to inform the construction of thenodes_allowednode mask, the actual mempolicy mode is ignored. That is, all modes behave like interleave over the resultingnodes_allowedmask 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 pagesnodes_allowedcommand 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: 0Default behavior [with or without this patch] balances persistent hugepage allocation across nodes [with sufficient contiguous memory]:
hugeadm --pool-pages-min=2048Kb:32yields:
Node 0 HugePages_Total: 8 Node 1 HugePages_Total: 8 Node 2 HugePages_Total: 8 Node 3 HugePages_Total: 8Applying 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:+8yields:
Node 0
HugePages_Total: 8
Node 1HugePages_Total: 8
Node 2HugePages_Total: 16
Node 3HugePages_Total: 8The 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:-8yields:
Node 0
HugePages_Total: 4
Node 1HugePages_Total: 4
Node 2HugePages_Total: 16
Node 3HugePages_Total: 8
Quoted 5 lines
The 8 huge pages freed were balanced over nodes 0 and 1.
Acked-by Mel Gorman <[email protected]>Signed-off-by Lee Schermerhorn <[email protected]>
This seems to behave as advertised and I could spot no other problems in the code so make that a;
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
rather than the other way around.
Quoted 158 lines
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
===================================================================mm/mempolicy.c +61
-0@@ -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
===================================================================include/linux/mempolicy.h +3
-0@@ -201,6 +201,7 @@ extern void mpol_fix_fork_child_flag(strextern 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_zonereturn 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
===================================================================mm/hugetlb.c +9
-5@@ -1248,10 +1248,13 @@ static int adjust_pool_surplus(struct hsstatic 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; }
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 3/6] hugetlb: derive huge pages nodes allowed from task mempolicy
In reply to Lee SchermerhornQuoted 16 lines · Lee Schermerhorn
Index:
linux-2.6.31-rc7-mmotm-090827-0057/mm/mempolicy.c
===================================================================mm/mempolicy.c +8
-0@@ -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
mm/mempolicy.c struct zonelist *huge_zonelist(struct vm · line 1584
Quoted 10 lines
mm/mempolicy.c +10
-0+* 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
Re: [PATCH 3/6] hugetlb: derive huge pages nodes allowed from task mempolicy
Quoted 23 lines · David Rientjes
Quoted 21 lines · Lee Schermerhorn
Index:
linux-2.6.31-rc7-mmotm-090827-0057/mm/mempolicy.c
===================================================================mm/mempolicy.c +13
-0@@ -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'
Quoted 8 lines
mm/mempolicy.c struct zonelist *huge_zonelist(struct vm · line 1584
Quoted 5 lines
mm/mempolicy.c +5
-0+* 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 inmempolicy.c, tho'.
Would this work for you?
Quoted 5 lines
It'd probably be better to check for a NULL
nodes_allowedeither inset_max_huge_pages()than in hstate_next_node_to_{alloc,free} just for the cleanliness of the code OR simply returnnode_online_mapfrom 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.
Quoted 4 lines
Otherwise
Acked-by David Rientjes <[email protected]>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 3/6] hugetlb: derive huge pages nodes allowed from task mempolicy
Quoted 12 lines · Lee Schermerhorn
Quoted 2 lines
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 inmempolicy.c, tho'.
Quoted 2 lines
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.
Quoted 11 lines
Quoted 4 lines
It'd probably be better to check for a NULL
nodes_allowedeither inset_max_huge_pages()than in hstate_next_node_to_{alloc,free} just for the cleanliness of the code OR simply returnnode_online_mapfrom 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_maptonodes_allowed. Then, I'll have to test for that condition before
callingkfree(). 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.
PATCH 4/6 hugetlb: introduce alloc_nodemask_of_node
In reply to Lee Schermerhorn[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.
include/linux/nodemask.h | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)
include/linux/nodemask.h +18 -2
@@ -245,18 +245,34 @@ static inline int __next_node(int n, conreturn 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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 4/6] hugetlb: introduce alloc_nodemask_of_node
Quoted 28 lines · Lee Schermerhorn
[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 thenodemask_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 <[email protected]>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
===================================================================
include/linux/nodemask.h static inline int __next_node(int n, con · line 251
Quoted 7 lines
include/linux/nodemask.h +4
-0@@ -245,18 +245,34 @@ static inline int __next_node(int n, conreturn 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.
Quoted 16 lines
include/linux/nodemask.h +4
-2#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().
include/linux/nodemask.h static inline int __next_node(int n, con · line 275
Quoted 10 lines
include/linux/nodemask.h +10
-0+*/ +#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.
Quoted 4 lines
include/linux/nodemask.h +0
-0#define first_unset_node (mask) __first_unset_node(&(mask))static inline int __first_unset_node (const nodemask_t *maskp) {
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 4/6] hugetlb: introduce alloc_nodemask_of_node
Quoted 32 lines · Mel Gorman
Quoted 31 lines · Lee Schermerhorn
[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 thenodemask_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 <[email protected]>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
===================================================================include/linux/nodemask.h +0
-0@@ -245,18 +245,34 @@ static inline int __next_node(int n, conreturn min_t (int,MAX_NUMNODES ,find_next_bit (srcp->bits,MAX_NUMNODES , n+1 )); }
Quoted 9 lines
include/linux/nodemask.h static inline int __next_node(int n, con · line 251
Quoted 4 lines
include/linux/nodemask.h +4
-0+#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
Quoted 14 lines
Quoted 14 lines
include/linux/nodemask.h +1
-2#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; \ })
Quoted 21 lines
include/linux/nodemask.h static inline int __next_node(int n, con · line 275
Quoted 13 lines
include/linux/nodemask.h +13
-0+/* +* 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.
Quoted 4 lines
include/linux/nodemask.h +0
-0#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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 4/6] hugetlb: introduce alloc_nodemask_of_node
Quoted 18 lines · Lee Schermerhorn
Quoted 8 lines
Quoted 8 lines
Index:
linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
===================================================================include/linux/nodemask.h +0
-0@@ -245,18 +245,34 @@ static inline int __next_node(int n, conreturn min_t (int,MAX_NUMNODES ,find_next_bit (srcp->bits,MAX_NUMNODES , n+1 )); }Quoted 9 lines
include/linux/nodemask.h static inline int __next_node(int n, con · line 251
Quoted 4 lines
include/linux/nodemask.h +4
-0+#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.
Quoted 6 lines
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
it is clear that I cc'd Mel on the initial proposal. If it is the other way around, for example,
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.
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
include/linux/nodemask.h +13
-0+/* +* 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; \ +}) +
Re: [PATCH 4/6] hugetlb: introduce alloc_nodemask_of_node
Quoted 27 lines · David Rientjes
Quoted 18 lines · Lee Schermerhorn
Quoted 8 lines
Quoted 8 lines
Index:
linux-2.6.31-rc7-mmotm-090827-0057/include/linux/nodemask.h
===================================================================include/linux/nodemask.h +0
-0@@ -245,18 +245,34 @@ static inline int __next_node(int n, conreturn min_t (int,MAX_NUMNODES ,find_next_bit (srcp->bits,MAX_NUMNODES , n+1 )); }Quoted 9 lines
include/linux/nodemask.h static inline int __next_node(int n, con · line 251
Quoted 4 lines
include/linux/nodemask.h +4
-0+#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.
Quoted 6 lines
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.
Quoted 4 lines
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 onnode_set()if nmp can't be allocated).
OK. That works. will be in v6
Quoted 22 lines
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 <[email protected]>Signed-off-by David Rientjes <[email protected]>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 <[email protected]>Cc Mel Gorman <[email protected]>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.
Quoted 8 lines
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.
???
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 4 lines
include/linux/nodemask.h +3
-0+/* +* returns pointer to kmalloc()'d nodemask initialized to contain the +* specified node. Caller must free with kfree(). include/linux/nodemask.h static inline int __next_node(int n, con · line 275
Quoted 10 lines
include/linux/nodemask.h +10
-0+*/ +#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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 4/6] hugetlb: introduce alloc_nodemask_of_node
Quoted 28 lines · Lee Schermerhorn
Quoted 28 lines
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 <[email protected]>Signed-off-by David Rientjes <[email protected]>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 <[email protected]>Cc Mel Gorman <[email protected]>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).
Quoted 4 lines
Quoted 1 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.
PATCH 5/6 hugetlb: add per node hstate attributes
In reply to Lee Schermerhorn[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
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(-)
drivers/base/node.c +33 -0
@@ -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, intsysdev_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); }
mm/hugetlb.c +215 -30
358 lines not on this page · raw message
include/linux/numa.h +2 -0
@@ -10,4 +10,6 @@#define MAX_NUMNODES (1 << NODES_SHIFT) +#define NO_NODEID_SPECIFIED (-1) +#endif /* _LINUX_NUMA_H */
include/linux/node.h +8 -0
@@ -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(unsextern 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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 5/6] hugetlb: add per node hstate attributes
Quoted 115 lines · Lee Schermerhorn
[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' inkobj_to_node_hstate()
+ rename (count, input) to (len, count) innr_hugepages_store()
+ moved per nodehugepages_kobjand hstate_kobjs[] from the struct node [sysdev] tohugetlb.cprivate 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.
+ replacedhugetlb.cprivate "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/oThe 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. Callingset_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 thenodes_allowedmask. 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 anodes_allowednode mask contain only the specified node.Setting the node specific
nr_hugepagesvia 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_hugepagesnr_hugepagessurplus_hugepagesStarting 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: 0vm.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: 0vm.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_hugepagesNode 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
Quoted 2 lines
Signed-off-by Lee Schermerhorn <[email protected]>
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
Quoted 481 lines
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
===================================================================drivers/base/node.c +33
-0@@ -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, intsysdev_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
===================================================================mm/hugetlb.c +215
-30@@ -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(voreturn ;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_taproc_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
===================================================================include/linux/numa.h +2
-0@@ -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
===================================================================include/linux/node.h +8
-0@@ -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(unsextern 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)
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 5/6] hugetlb: add per node hstate attributes
In reply to Lee SchermerhornQuoted 299 lines · Lee Schermerhorn
Index:
linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================mm/hugetlb.c +164
-29@@ -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(voreturn ;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)
mm/hugetlb.c static void __init hugetlb_sysfs_init(vo · line 1605
Quoted 10 lines
mm/hugetlb.c +10
-0+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?
mm/hugetlb.c static void __init hugetlb_sysfs_init(vo · line 1616
Quoted 11 lines
mm/hugetlb.c +11
-0+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.
Quoted 57 lines
mm/hugetlb.c +30
-1+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_taproc_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
===================================================================
include/linux/numa.h line 15
Quoted 6 lines
include/linux/numa.h +2
-0@@ -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!
Re: [PATCH 5/6] hugetlb: add per node hstate attributes
Quoted 306 lines · David Rientjes
Quoted 304 lines · Lee Schermerhorn
Index:
linux-2.6.31-rc7-mmotm-090827-0057/mm/hugetlb.c
===================================================================mm/hugetlb.c +169
-29@@ -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(voreturn ;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,
Quoted 8 lines
mm/hugetlb.c static void __init hugetlb_sysfs_init(vo · line 1605
Quoted 5 lines
mm/hugetlb.c +5
-0+ &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
-ENOMEMcondition or sysfs problem?
Just the raw negative number?
Quoted 15 lines
mm/hugetlb.c static void __init hugetlb_sysfs_init(vo · line 1616
Quoted 12 lines
mm/hugetlb.c +11
-0+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.
Quoted 61 lines
Quoted 61 lines
mm/hugetlb.c +30
-1+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_taproc_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
===================================================================include/linux/numa.h +0
-0@@ -10,4 +10,6 @@#define MAX_NUMNODES (1 << NODES_SHIFT)
Quoted 8 lines
include/linux/numa.h line 15
Quoted 3 lines
include/linux/numa.h +2
-0+#define NO_NODEID_SPECIFIED (-1) +#endif /* _LINUX_NUMA_H */ Hmm, so we already have
NUMA_NO_NODEin the ia64 andx86_64code andNID_INVALin the ACPI code, both of which are defined to -1. Maybe rename your addition here in favor ofNUMA_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 :).
Quoted 2 lines
Thanks for doing this!
Well, we do need this, as well.
Re: [PATCH 5/6] hugetlb: add per node hstate attributes
Quoted 105 lines · Lee Schermerhorn
Quoted 96 lines
Quoted 96 lines
mm/hugetlb.c +85
-1@@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(voreturn ;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,Quoted 8 lines
mm/hugetlb.c static void __init hugetlb_sysfs_init(vo · line 1605
Quoted 5 lines
mm/hugetlb.c +5
-0+ &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
-ENOMEMcondition or sysfs problem?
Quoted 2 lines
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.
Quoted 17 lines
Quoted 15 lines
mm/hugetlb.c static void __init hugetlb_sysfs_init(vo · line 1616
Quoted 12 lines
mm/hugetlb.c +11
-0+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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
I.e., would the
node driver get called to register the attributes in this case?
Not without a MEM_ONLINE notifier.
Quoted 5 lines
Maybe
that case doesn't exist, so I don't have to worry about it. I think
this is somewhat similar to the top cpusetmems_allowedbeing 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.
Quoted 17 lines
Quoted 8 lines
Quoted 8 lines
Index:
linux-2.6.31-rc7-mmotm-090827-0057/include/linux/numa.h
===================================================================include/linux/numa.h +0
-0@@ -10,4 +10,6 @@#define MAX_NUMNODES (1 << NODES_SHIFT)Quoted 8 lines
include/linux/numa.h line 15
Quoted 3 lines
include/linux/numa.h +2
-0+#define NO_NODEID_SPECIFIED (-1) +#endif /* _LINUX_NUMA_H */ Hmm, so we already have
NUMA_NO_NODEin the ia64 andx86_64code andNID_INVALin the ACPI code, both of which are defined to -1. Maybe rename your addition here in favor ofNUMA_NO_NODE, remove it from the ia64 and x86 arch headers, and convert the ACPI code?
Quoted 3 lines
OK, replacing '
NO_NODEID_SPECIFIED' with 'NUMA_NO_NODE,' works w/o decending into header dependency hell. The symbol is already visible inhugetlb.cI'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.
Quoted 1 line
But, ACPI? Not today, thanks :).
Darn :)
Re: [PATCH 5/6] hugetlb: add per node hstate attributes
Quoted 110 lines · David Rientjes
Quoted 105 lines · Lee Schermerhorn
Quoted 96 lines
Quoted 96 lines
mm/hugetlb.c +85
-1@@ -1451,17 +1507,143 @@ static void __init hugetlb_sysfs_init(voreturn ;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,Quoted 8 lines
mm/hugetlb.c static void __init hugetlb_sysfs_init(vo · line 1605
Quoted 5 lines
mm/hugetlb.c +5
-0+ &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
-ENOMEMcondition or sysfs problem?Quoted 2 lines
Just the raw negative number?
Quoted 6 lines
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
Quoted 18 lines
Quoted 18 lines
Quoted 16 lines
mm/hugetlb.c static void __init hugetlb_sysfs_init(vo · line 1616
Quoted 13 lines
mm/hugetlb.c +11
-0+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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 5 lines
Quoted 4 lines
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.
Quoted 7 lines
If memory hotplug doesn't update nodes_state[N_HIGH_MEMORY] then there are plenty of other users that will currently fail as well.
Quoted 2 lines
I.e., would the
node driver get called to register the attributes in this case?Not without a
MEM_ONLINEnotifier.
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.
Quoted 7 lines
Quoted 6 lines
Maybe
that case doesn't exist, so I don't have to worry about it. I think
this is somewhat similar to the top cpusetmems_allowedbeing set to all possible to cover any subsequently added nodes/memory.
Quoted 5 lines
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.
Quoted 1 line
PATCH 6/6 hugetlb: update hugetlb documentation for mempolicy based management.
In reply to Lee Schermerhorn[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.
Documentation/vm/hugetlbpage.txt | 257 ++++++++++++++++++++++++++------------- 1 file changed, 172 insertions(+), 85 deletions(-)
Documentation/vm/hugetlbpage.txt +172 -85
@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 6 lines · Lee Schermerhorn
[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.
Quoted 7 lines
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 <[email protected]>
Adding Randy to the cc. Comments below, but otherwise:
Quoted 16 lines
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
===================================================================Documentation/vm/hugetlbpage.txt +1
-1@@ -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
Documentation/vm/hugetlbpage.txt This optimization is more critical now a · line 24
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +4
-2(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.
Quoted 34 lines
Documentation/vm/hugetlbpage.txt +3
-23+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. -
Documentation/vm/hugetlbpage.txt HugePages_Surp is short for "surplus," · line 59
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +6
-4-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.
Quoted 31 lines
Documentation/vm/hugetlbpage.txt +17
-6+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:
Documentation/vm/hugetlbpage.txt with a huge page size selection paramete · line 91
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +4
-3echo 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'.
Documentation/vm/hugetlbpage.txt with a huge page size selection paramete · line 93
Quoted 2 lines
Documentation/vm/hugetlbpage.txt +2
-0+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.
Documentation/vm/hugetlbpage.txt with a huge page size selection paramete · line 95
Quoted 2 lines
Documentation/vm/hugetlbpage.txt +2
-0+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?
Quoted 56 lines
Documentation/vm/hugetlbpage.txt +15
-20+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
Documentation/vm/hugetlbpage.txt distribution of huge pages in a NUMA sys · line 142
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +9
-0+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!
Quoted 33 lines
Documentation/vm/hugetlbpage.txt +16
-5With 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.
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 186
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +10
-0+ +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.
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 199
Quoted 13 lines
Documentation/vm/hugetlbpage.txt +13
-0+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.
Quoted 8 lines
Documentation/vm/hugetlbpage.txt +8
-0+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
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 217
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +10
-0+ 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.
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 224
Quoted 7 lines
Documentation/vm/hugetlbpage.txt +7
-0+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"?
Quoted 100 lines
Documentation/vm/hugetlbpage.txt +45
-21+ + +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) {
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 40 lines · David Rientjes
Quoted 6 lines · Lee Schermerhorn
[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.
Quoted 7 lines
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 <[email protected]>Adding Randy to the cc. Comments below, but otherwise:
Acked-by David Rientjes <[email protected]>Quoted 20 lines
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
===================================================================Documentation/vm/hugetlbpage.txt +1
-1@@ -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.
Quoted 8 lines
Documentation/vm/hugetlbpage.txt This optimization is more critical now a · line 24
Quoted 6 lines
Documentation/vm/hugetlbpage.txt +4
-2-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 theDon't think the brackets are needed.
will fix
Quoted 39 lines
Quoted 39 lines
Documentation/vm/hugetlbpage.txt +3
-27+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.
Quoted 8 lines
Documentation/vm/hugetlbpage.txt HugePages_Surp is short for "surplus," · line 59
Quoted 6 lines
Documentation/vm/hugetlbpage.txt +6
-0+/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" ???
Quoted 34 lines
Quoted 34 lines
Documentation/vm/hugetlbpage.txt +17
-6+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
Quoted 10 lines
Documentation/vm/hugetlbpage.txt with a huge page size selection paramete · line 91
Quoted 8 lines
Documentation/vm/hugetlbpage.txt +4
-3-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 thatRemove the first 'the'.
OK.
Quoted 8 lines
Documentation/vm/hugetlbpage.txt with a huge page size selection paramete · line 93
Quoted 3 lines
Documentation/vm/hugetlbpage.txt +2
-0+modifies nr_hugepages that contain sufficient available contiguous memory. +These nodes are called the huge pages "allowed nodes". The default for theNot 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_allowedis "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.
Quoted 5 lines
Documentation/vm/hugetlbpage.txt with a huge page size selection paramete · line 95
Quoted 3 lines
Documentation/vm/hugetlbpage.txt +2
-0+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 memoryAll 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.
Quoted 112 lines
Quoted 57 lines
Documentation/vm/hugetlbpage.txt +15
-20+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'sDocumentation/vm/hugetlbpage.txt distribution of huge pages in a NUMA sys · line 142
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +9
-0+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!
Quoted 42 lines
Documentation/vm/hugetlbpage.txt +25
-5With 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>.
Quoted 8 lines
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 186
Quoted 1 line
Documentation/vm/hugetlbpage.txt +1
-0+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 tonr_hugepages, regardless of their mempolicy. It's now possible that hugepages will remain allocated because they are on nodes disjoint fromcurrent->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 :)]
Quoted 8 lines
Quoted 8 lines
Documentation/vm/hugetlbpage.txt +8
-0+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
Quoted 8 lines
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 199
Quoted 5 lines
Documentation/vm/hugetlbpage.txt +5
-0+ 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.
Quoted 30 lines
Quoted 9 lines
Documentation/vm/hugetlbpage.txt +8
-0+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 beDocumentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 217
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +10
-0+ 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.
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 224
Quoted 7 lines
Documentation/vm/hugetlbpage.txt +7
-0+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.
Quoted 2 lines
Implementation detail in the name, maybe just say "all online nodes with memory"?
OK. will fix for V6. soon come, I hope.
Quoted 98 lines
Quoted 98 lines
Documentation/vm/hugetlbpage.txt +45
-21+ + +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
Quoted 3 lines
Documentation/vm/hugetlbpage.txt int main(void) · line 417
Quoted 3 lines
Documentation/vm/hugetlbpage.txt +0
-0void check_bytes(char *addr) {
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 33 lines · Lee Schermerhorn
Quoted 24 lines
Quoted 24 lines
Documentation/vm/hugetlbpage.txt +0
-20@@ -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.Quoted 8 lines
Documentation/vm/hugetlbpage.txt HugePages_Surp is short for "surplus," · line 59
Quoted 6 lines
Documentation/vm/hugetlbpage.txt +6
-0+/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.
Quoted 3 lines
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.
Quoted 11 lines
Quoted 4 lines
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_allowedis "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.
Quoted 13 lines
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:
Quoted 8 lines
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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 86 lines · David Rientjes
Quoted 33 lines · Lee Schermerhorn
Quoted 24 lines
Quoted 24 lines
Documentation/vm/hugetlbpage.txt +0
-20@@ -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.Quoted 8 lines
Documentation/vm/hugetlbpage.txt HugePages_Surp is short for "surplus," · line 59
Quoted 6 lines
Documentation/vm/hugetlbpage.txt +6
-0+/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.
Quoted 3 lines
I don't see what in the text you're referring to" "preallocated" vs "already in use" ???
Your new line, "
/proc/sys/vm/nr_hugepagesindicates 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.Quoted 11 lines
Quoted 4 lines
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_allowedis "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.
Quoted 13 lines
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:
Quoted 8 lines
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 :)]
Quoted 6 lines
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.
Quoted 4 lines
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.
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 7 lines · Mel Gorman
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
Quoted 4 lines
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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 17 lines · David Rientjes
Quoted 7 lines · Mel Gorman
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 3 lines
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_hugepageshas 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.
Quoted 5 lines
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.
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 10 lines · Mel Gorman
Quoted 3 lines
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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 18 lines · David Rientjes
Quoted 10 lines · Mel Gorman
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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
Quoted 5 lines
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.
Quoted 6 lines
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.
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 2 lines · Mel Gorman
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.
Quoted 3 lines
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.
Quoted 7 lines
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 tonr_hugepageswhen 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.
Quoted 8 lines
Quoted 4 lines
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_hugepageswould 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. ]
Quoted 9 lines
It also appeared obvious
to me that it's how the interface should behave even if it wasn't doing it in practice. Oncenr_hugepagesobeys 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 beingnumactl -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.
Quoted 7 lines
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.
Quoted 5 lines
It's likely that writing to the
globalnr_hugepageswithin a mempolicy will end up with a more sensible result than a userspace application dealing with the individual node-specificnr_hugepagesfiles.
Disagree for the interleave example above without complex userspace logic to determine how successful hugepage allocation will be based on fragmentation.
Quoted 8 lines
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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 8 lines · David Rientjes
Quoted 2 lines · Mel Gorman
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.
Quoted 12 lines
Quoted 3 lines
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.
Quoted 5 lines
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?
Quoted 13 lines
Quoted 7 lines
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 tonr_hugepageswhen 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.
Quoted 6 lines
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.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
That
was not the behavior over the past three or four years until this patchset.
Quoted 8 lines
Quoted 3 lines
While this is true, I know people have also been bitten by the expectation that writing to
nr_hugepageswould 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.
Quoted 3 lines
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.
Quoted 3 lines
[ 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.
Quoted 7 lines
Quoted 7 lines
It also appeared obvious
to me that it's how the interface should behave even if it wasn't doing it in practice. Oncenr_hugepagesobeys 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
Quoted 7 lines
Quoted 2 lines
numactl -m x,y,z hugeadm --pool-pages-min $PAGESIZE:$NUMPAGES
We need a new mempolicy flag, then, such as
MPOL_F_HUGEPAGESto 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.
Quoted 8 lines
Quoted 7 lines
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.
Quoted 7 lines
That "burden" is usually for good reason: if my
MPOL_INTERLEAVEpolicy 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.
Quoted 9 lines
That's not a trivial performance
gain and can rarely be dismissed by simply picking an arbitrary set.Quoted 5 lines
It's likely that writing to the
globalnr_hugepageswithin a mempolicy will end up with a more sensible result than a userspace application dealing with the individual node-specificnr_hugepagesfiles.
Quoted 4 lines
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.
Quoted 9 lines
Quoted 8 lines
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.
Quoted 4 lines
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.
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 6 lines · Mel Gorman
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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 9 lines · David Rientjes
Quoted 6 lines · Mel Gorman
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.
Quoted 8 lines
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.
Quoted 4 lines
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.
Quoted 9 lines
The documentation
(Documentation/vm/hugetlbpage.txt) has always said/proc/sys/vm/nr_hugepaegsaffects 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.
Quoted 9 lines
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.
---
include/linux/hugetlb.h | 1 + kernel/sysctl.c | 11 +++++++++++ mm/hugetlb.c | 35 ++++++++++++++++++++++++++++++++--- 3 files changed, 44 insertions(+), 3 deletions(-)
include/linux/hugetlb.h +1 -0
@@ -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 *);
kernel/sysctl.c +11 -0
@@ -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",
mm/hugetlb.c +32 -3
@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 10 lines · Mel Gorman
Quoted 3 lines
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.
Quoted 7 lines
I hate to have to do this, but how about
nr_hugepageswhich acts system-wide as it did traditionally andnr_hugepages_mempolicythat 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.
Quoted 3 lines
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?
Quoted 18 lines
==== 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_hugepagesfrom processes that are running within a memory policy. This patch adds/proc/sys/vm/nr_hugepages_mempolicywhich when written to will obey memory policies./proc/sys/vm/nr_hugepagescontinues then to be a system-wide tunable regardless of memory policy.
Quoted 7 lines
Signed-off-by Mel Gorman <[email protected]>---
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.
Quoted 39 lines
include/linux/hugetlb.h +1
-0@@ -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 *);kernel/sysctl.c +11
-0@@ -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",mm/hugetlb.c +0
-0
mm/hugetlb.c static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, · line 1250
Quoted 7 lines
mm/hugetlb.c +1
-0@@ -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.
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 13 lines · David Rientjes
Quoted 10 lines · Mel Gorman
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 10 lines
Quoted 7 lines
I hate to have to do this, but how about
nr_hugepageswhich acts system-wide as it did traditionally andnr_hugepages_mempolicythat 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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 26 lines
Quoted 18 lines
==== 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_hugepagesfrom processes that are running within a memory policy. This patch adds/proc/sys/vm/nr_hugepages_mempolicywhich when written to will obey memory policies./proc/sys/vm/nr_hugepagescontinues then to be a system-wide tunable regardless of memory policy.Quoted 7 lines
Signed-off-by Mel Gorman <[email protected]>---
include/linux/hugetlb.h | 1 + kernel/sysctl.c | 11 +++++++++++ mm/hugetlb.c | 35 ++++++++++++++++++++++++++++++++--- 3 files changed, 44 insertions(+), 3 deletions(-)
Quoted 4 lines
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.
Quoted 51 lines
Quoted 39 lines
include/linux/hugetlb.h +1
-0@@ -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 *);kernel/sysctl.c +11
-0@@ -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",mm/hugetlb.c +0
-0mm/hugetlb.c static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, · line 1250
Quoted 7 lines
mm/hugetlb.c +1
-0@@ -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_MEMPOLICYif the nodemask was allocated in the sysctl handler instead and passing it intoset_max_huge_pages()instead of a nid. Lee, what do you think?
Quoted 4 lines
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.
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 75 lines · Mel Gorman
Quoted 13 lines · David Rientjes
Quoted 10 lines · Mel Gorman
Quoted 3 lines
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.Quoted 4 lines
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.
Quoted 10 lines
Quoted 7 lines
I hate to have to do this, but how about
nr_hugepageswhich acts system-wide as it did traditionally andnr_hugepages_mempolicythat 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.
Quoted 7 lines
Quoted 3 lines
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/buddyinfofor example but the sysfs directories for the fake nodes were not created sonr_hugepagescouldn't be examined on a per-node basis for example.Quoted 26 lines
Quoted 25 lines
==== 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_hugepagesfrom processes that are running within a memory policy. This patch adds/proc/sys/vm/nr_hugepages_mempolicywhich when written to will obey memory policies./proc/sys/vm/nr_hugepagescontinues then to be a system-wide tunable regardless of memory policy.Signed-off-by Mel Gorman <[email protected]>---
include/linux/hugetlb.h | 1 + kernel/sysctl.c | 11 +++++++++++ mm/hugetlb.c | 35 ++++++++++++++++++++++++++++++++--- 3 files changed, 44 insertions(+), 3 deletions(-)
Quoted 6 lines
Quoted 4 lines
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:
Quoted 43 lines
Quoted 43 lines
Quoted 43 lines
include/linux/hugetlb.h +1
-0@@ -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 *);kernel/sysctl.c +11
-0@@ -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",mm/hugetlb.c +0
-0@@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,return ret; }
Quoted 1 line
Quoted 1 line
mm/hugetlb.c static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, · line 1247
Quoted 1 line
mm/hugetlb.c +1
-0+#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.
Quoted 8 lines
Quoted 8 lines
mm/hugetlb.c static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, · line 1250
Quoted 3 lines
mm/hugetlb.c +0
-0#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_MEMPOLICYif the nodemask was allocated in the sysctl handler instead and passing it intoset_max_huge_pages()instead of a nid. Lee, what do you think?
Quoted 7 lines
Quoted 4 lines
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
Quoted 1 line
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 76 lines · Lee Schermerhorn
Quoted 75 lines · Mel Gorman
Quoted 13 lines · David Rientjes
Quoted 10 lines · Mel Gorman
Quoted 3 lines
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.Quoted 4 lines
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.
Quoted 10 lines
Quoted 7 lines
I hate to have to do this, but how about
nr_hugepageswhich acts system-wide as it did traditionally andnr_hugepages_mempolicythat 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.
Quoted 7 lines
Quoted 3 lines
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/buddyinfofor example but the sysfs directories for the fake nodes were not created sonr_hugepagescouldn't be examined on a per-node basis for example.Quoted 26 lines
Quoted 25 lines
==== 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_hugepagesfrom processes that are running within a memory policy. This patch adds/proc/sys/vm/nr_hugepages_mempolicywhich when written to will obey memory policies./proc/sys/vm/nr_hugepagescontinues then to be a system-wide tunable regardless of memory policy.Signed-off-by Mel Gorman <[email protected]>---
include/linux/hugetlb.h | 1 + kernel/sysctl.c | 11 +++++++++++ mm/hugetlb.c | 35 ++++++++++++++++++++++++++++++++--- 3 files changed, 44 insertions(+), 3 deletions(-)
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
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.
Quoted 46 lines
Also, see below:
Quoted 43 lines
Quoted 43 lines
Quoted 43 lines
include/linux/hugetlb.h +1
-0@@ -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 *);kernel/sysctl.c +11
-0@@ -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",mm/hugetlb.c +0
-0@@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,return ret; }
Quoted 6 lines
Quoted 1 line
Quoted 1 line
mm/hugetlb.c static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, · line 1247
Quoted 1 line
mm/hugetlb.c +1
-0+#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)How about defining
NUMA_NO_NODE_OBEY_MEMPOLICYas (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_MEMPOLICYis private to hugetlb at this time.
That seems reasonable.
Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
mm/hugetlb.c static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, · line 1250
Quoted 3 lines
mm/hugetlb.c +0
-0#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_MEMPOLICYif the nodemask was allocated in the sysctl handler instead and passing it intoset_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.
Quoted 6 lines
Quoted 2 lines
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/*
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 8 lines · Mel Gorman
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
mm/hugetlb.c +0
-0@@ -1244,6 +1244,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,return ret; }
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Quoted 1 line
mm/hugetlb.c static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, · line 1247
Quoted 1 line
mm/hugetlb.c +1
-0+#define NUMA_NO_NODE_OBEY_MEMPOLICY (-2)How about defining
NUMA_NO_NODE_OBEY_MEMPOLICYas (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_MEMPOLICYis 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.
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 17 lines · David Rientjes
Quoted 15 lines · Mel Gorman
Quoted 14 lines
Quoted 9 lines
Quoted 9 lines
mm/hugetlb.c static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, · line 1247
Quoted 9 lines
mm/hugetlb.c +1
-0@@ -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_MEMPOLICYas (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_MEMPOLICYis private to hugetlb at this time.
Quoted 7 lines
Quoted 2 lines
That seems reasonable.
If the nodemask allocation is moved to the sysctl handler and
nodemask_tis passed intoset_max_huge_pages()instead of nid, you don't needNUMA_NO_NODE_OBEY_MEMPOLICYat 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.
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
In reply to Mel GormanQuoted 10 lines · Mel Gorman
Quoted 3 lines
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/buddyinfofor example but the sysfs directories for the fake nodes were not created sonr_hugepagescouldn'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.
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 11 lines · David Rientjes
Quoted 6 lines
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/buddyinfofor example but the sysfs directories for the fake nodes were not created sonr_hugepagescouldn'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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 26 lines · David Rientjes
Quoted 11 lines · David Rientjes
Quoted 6 lines
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/buddyinfofor example but the sysfs directories for the fake nodes were not created sonr_hugepagescouldn'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
Quoted 6 lines
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_EMUnow, 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.
Quoted 2 lines
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.
Signature · 9 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
In reply to Lee SchermerhornOn Fri, 28 Aug 2009 12:03:51 -0400 Lee Schermerhorn wrote:
(Thanks for cc:, David.)
Quoted 44 lines
[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 <[email protected]>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
===================================================================Documentation/vm/hugetlbpage.txt +0
-18@@ -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
Documentation/vm/hugetlbpage.txt HugePages_Surp is short for "surplus," · line 61
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +8
-2-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
Documentation/vm/hugetlbpage.txt HugePages_Surp is short for "surplus," · line 67
Quoted 6 lines
Documentation/vm/hugetlbpage.txt +6
-0+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.
Documentation/vm/hugetlbpage.txt HugePages_Surp is short for "surplus," · line 71
Quoted 4 lines
Documentation/vm/hugetlbpage.txt +4
-0+ +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"
Documentation/vm/hugetlbpage.txt HugePages_Surp is short for "surplus," · line 72
Quoted 1 line
Documentation/vm/hugetlbpage.txt +1
-0+or preallocating huge pages as memory has not yet become fragmented.
of
Quoted 18 lines
Documentation/vm/hugetlbpage.txt +4
-6Some 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:
Documentation/vm/hugetlbpage.txt with a huge page size selection paramete · line 91
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +4
-3echo 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"
Documentation/vm/hugetlbpage.txt with a huge page size selection paramete · line 92
Quoted 1 line
Documentation/vm/hugetlbpage.txt +1
-0+modifies nr_hugepages that contain sufficient available contiguous memory.
whoa. too many "that"s. confusing.
Quoted 9 lines
Documentation/vm/hugetlbpage.txt +5
-0+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
...
Quoted 29 lines
Documentation/vm/hugetlbpage.txt +6
-12@@ -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
Documentation/vm/hugetlbpage.txt distribution of huge pages in a NUMA sys · line 137
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +7
-3-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 ;)
Quoted 28 lines
Documentation/vm/hugetlbpage.txt +10
-5+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:
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 176
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +10
-0+ +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 '.'
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 180
Quoted 4 lines
Documentation/vm/hugetlbpage.txt +4
-0+ +or, more succinctly: + + numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages.
ditto
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 188
Quoted 8 lines
Documentation/vm/hugetlbpage.txt +8
-0+ +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:
Quoted 8 lines
Documentation/vm/hugetlbpage.txt +8
-0+ +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
Documentation/vm/hugetlbpage.txt Inside each of these directories, the sa · line 206
Quoted 10 lines
Documentation/vm/hugetlbpage.txt +10
-0+ 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.
Quoted 54 lines
Documentation/vm/hugetlbpage.txt +50
-0+ 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.
...
Quoted 1 line
Documentation/vm/hugetlbpage.txt +0
-0@@ -237,14 +334,8 @@ map_hugetlb.c.
...
Quoted 1 line
Documentation/vm/hugetlbpage.txt +0
-0@@ -302,10 +393,12 @@ int main(void)
...
Documentation/vm/hugetlbpage.txt int main(void)
Quoted 1 line
Documentation/vm/hugetlbpage.txt +0
-0@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
Quoted 3 lines · Randy Dunlap
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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>