hugetlb: numafy several functions
Subsystems (3)
PATCH 1/3 hugetlb: numafy several functions
Add node-parameterized helpers for dequeue_huge_page, alloc_fresh_huge_page, adjust_pool_surplus and try_to_free_low. Also have update_and_free_page() take a nid parameter. These changes are necessary to add sysfs attributes to specify the number of hugepages on NUMA nodes.
mm/hugetlb.c +56 -36
@@ -70,6 +70,20 @@ static void enqueue_huge_page(struct page *page) free_huge_pages_node[nid]++; } +static struct page *dequeue_huge_page_node (struct vm_area_struct *vma, +int nid) +{ +struct page *page; + + page = list_entry(hugepage_freelists[nid].next, struct page, lru); +list_del (&page->lru); + free_huge_pages--; + free_huge_pages_node[nid]--; +if (vma && vma->vm_flags &VM_MAYSHARE ) + resv_huge_pages--; +return page; +} +static struct page *dequeue_huge_page (struct vm_area_struct *vma,unsigned long address) {
@@ -84,13 +98,7 @@ static struct page *dequeue_huge_page(struct vm_area_struct *vma, nid =zone_to_nid (*z);if (cpuset_zone_allowed_softwall (*z, htlb_alloc_mask) && !list_empty (&hugepage_freelists[nid])) { - page =list_entry (hugepage_freelists[nid].next, - struct page, lru); -list_del (&page->lru); - free_huge_pages--; - free_huge_pages_node[nid]--; -if (vma && vma->vm_flags &VM_MAYSHARE ) - resv_huge_pages--; + page =dequeue_huge_page_node (vma, nid);break ; } }
@@ -98,11 +106,11 @@ static struct page *dequeue_huge_page(struct vm_area_struct *vma,return page; } -static void update_and_free_page (struct page *page) +static void update_and_free_page (int nid,struct page *page) {int i; nr_huge_pages--; - nr_huge_pages_node[page_to_nid (page)]--; + nr_huge_pages_node[nid]--;for (i =0 ; i < (HPAGE_SIZE /PAGE_SIZE ); i++) { page[i].flags &= ~(1 << PG_locked | 1 << PG_error | 1 << PG_referenced | 1 << PG_dirty | 1 << PG_active | 1 << PG_reserved |
@@ -124,7 +132,7 @@ static void free_huge_page(struct page *page)spin_lock (&hugetlb_lock);if (surplus_huge_pages_node[nid]) { -update_and_free_page (page); +update_and_free_page (nid, page); surplus_huge_pages--; surplus_huge_pages_node[nid]--; }else {
@@ -141,6 +149,18 @@ static void free_huge_page(struct page *page)* balanced by operating on them in a round-robin fashion. * Returns 1 if an adjustment was made. */ +static int adjust_pool_surplus_node (int delta,int nid) +{ +if (delta <0 && !surplus_huge_pages_node[nid]) +return 0 ; +if (delta >0 && surplus_huge_pages_node[nid] >= + nr_huge_pages_node[nid]) +return 0 ; + surplus_huge_pages += delta; + surplus_huge_pages_node[nid] += delta; +return 1 ; +} +static int adjust_pool_surplus (int delta) {static int prev_nid;
@@ -152,19 +172,9 @@ static int adjust_pool_surplus(int delta) nid =next_node (nid, node_online_map);if (nid ==MAX_NUMNODES ) nid =first_node (node_online_map); - -/* To shrink on this node, there must be a surplus page */ -if (delta <0 && !surplus_huge_pages_node[nid]) -continue ; -/* Surplus cannot exceed the total number of pages */ -if (delta >0 && surplus_huge_pages_node[nid] >= - nr_huge_pages_node[nid]) -continue ; - - surplus_huge_pages += delta; - surplus_huge_pages_node[nid] += delta; - ret =1 ; -break ; + ret =adjust_pool_surplus_node (delta, nid); +if (ret ==1 ) +break ; }while (nid != prev_nid); prev_nid = nid;
@@ -384,7 +394,7 @@ static void return_unused_surplus_pages(unsigned long unused_resv_pages) page =list_entry (hugepage_freelists[nid].next, struct page, lru);list_del (&page->lru); -update_and_free_page (page); +update_and_free_page (nid, page); free_huge_pages--; free_huge_pages_node[nid]--; surplus_huge_pages--;
@@ -489,25 +499,35 @@ static unsigned int cpuset_mems_nr(unsigned int *array)#ifdef CONFIG_SYSCTL #ifdef CONFIG_HIGHMEM +static void try_to_free_low_node (unsigned long count,int nid) +{ +struct page *page, *next; +list_for_each_entry_safe (page, next, &hugepage_freelists[nid], lru) { +if (PageHighMem (page)) +continue ; +list_del (&page->lru); +update_and_free_page (nid, page); + free_huge_pages--; + free_huge_pages_node[nid]--; +if (count >= nr_huge_pages_node[nid]) +return ; + } +} +static void try_to_free_low (unsigned long count) {int i;for (i =0 ; i <MAX_NUMNODES ; ++i) { -struct page *page, *next; -list_for_each_entry_safe (page, next, &hugepage_freelists[i], lru) { -if (count >= nr_huge_pages) -return ; -if (PageHighMem (page)) -continue ; -list_del (&page->lru); -update_and_free_page (page); - free_huge_pages--; - free_huge_pages_node[page_to_nid (page)]--; - } +try_to_free_low_node (count, i); +if (count >= nr_huge_pages) +return ; } }#else +static inline void try_to_free_low_node (unsigned long count,int nid) +{ +}static inline void try_to_free_low (unsigned long count) { }
@@ -572,7 +592,7 @@ static unsigned long set_max_huge_pages(unsigned long count)struct page *page =dequeue_huge_page (NULL ,0 );if (!page)break ; -update_and_free_page (page); +update_and_free_page (page_to_nid (page), page); }while (count < persistent_huge_pages) {if (!adjust_pool_surplus (1 ))
--
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/3 hugetlb: add per-node nr_hugepages sysfs attribute
Allow specifying the number of hugepages to allocate on a particular node. Our current global sysctl will try its best to put hugepages equally on each node, but htat may not always be desired. This allows the admin to control the layout of hugepage allocation at a finer level (while not breaking the existing interface). Add callbacks in the sysfs node registration and unregistration functions into hugetlb to add the nr_hugepages attribute, which is a no-op if !NUMA or !HUGETLB.
---
Greg, do I need to add documentation for this sysfs attribute to Documentation/ABI? I'm not sure if I should just add a file in testing/ for just this attribute or should defer and create documentation for all of the /sys/devices/system/node information?
I was hoping to have the per-node nr_overcommit_hugepages done by this point, however it's a bit trickier. Do folks (Lee?) think it would actually be needed for their platforms? It adds quite a bit of locking overhead to the dynamic pool path to keep the counters sane, which might obviate the relatively high performance of the dynamic path.
drivers/base/node.c +2 -0
@@ -152,6 +152,7 @@ int register_node(struct node *node, int num, struct node *parent)sysdev_create_file (&node->sysdev, &attr_meminfo);sysdev_create_file (&node->sysdev, &attr_numastat);sysdev_create_file (&node->sysdev, &attr_distance); +hugetlb_register_node (node); }return error; }
@@ -169,6 +170,7 @@ void unregister_node(struct node *node)sysdev_remove_file (&node->sysdev, &attr_meminfo);sysdev_remove_file (&node->sysdev, &attr_numastat);sysdev_remove_file (&node->sysdev, &attr_distance); +hugetlb_unregister_node (node);sysdev_unregister (&node->sysdev); }
include/linux/hugetlb.h +11 -0
@@ -6,7 +6,9 @@#ifdef CONFIG_HUGETLB_PAGE #include <linux/mempolicy.h> +#include <linux/node.h> #include <linux/shm.h> +#include <linux/sysdev.h> #include <asm/tlbflush.h> struct ctl_table ;
@@ -26,6 +28,13 @@ void __unmap_hugepage_range(struct vm_area_struct *, unsigned long, unsigned lonint hugetlb_prefault (struct address_space *,struct vm_area_struct *);int hugetlb_report_meminfo (char *);int hugetlb_report_node_meminfo (int ,char *); +#ifdef CONFIG_NUMA +int hugetlb_register_node (struct node *); +void hugetlb_unregister_node (struct node *); +#else +#define hugetlb_register_node (node) do {} while(0) +#define hugetlb_unregister_node (node) do {} while(0) +#endif unsigned long hugetlb_total_pages (void );int hugetlb_fault (struct mm_struct *mm,struct vm_area_struct *vma,unsigned long address,int write_access);
@@ -114,6 +123,8 @@ static inline unsigned long hugetlb_total_pages(void)#define unmap_hugepage_range (vma, start, end) BUG()#define hugetlb_report_meminfo (buf) 0#define hugetlb_report_node_meminfo (n, buf) 0 +#define hugetlb_register_node (node) do {} while(0) +#define hugetlb_unregister_node (node) do {} while(0)#define follow_huge_pmd (mm, addr, pmd, write) NULL#define prepare_hugepage_range (addr,len) (-EINVAL)#define pmd_huge (x) 0
mm/hugetlb.c +118 -4
147 lines not on this page · raw message
--
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/3 hugetlb: add per-node nr_hugepages sysfs attribute
Quoted 1 line · Nishanth Aravamudan
hugetlb: add per-node
nr_hugepagessysfs attribute
Sorry, a few checkpatch errors slipped through, fixed below.
hugetlb: add per-node nr_hugepages sysfs attribute
Allow specifying the number of hugepages to allocate on a particular node. Our current global sysctl will try its best to put hugepages equally on each node, but htat may not always be desired. This allows the admin to control the layout of hugepage allocation at a finer level (while not breaking the existing interface). Add callbacks in the sysfs node registration and unregistration functions into hugetlb to add the nr_hugepages attribute, which is a no-op if !NUMA or !HUGETLB.
drivers/base/node.c +2 -0
@@ -152,6 +152,7 @@ int register_node(struct node *node, int num, struct node *parent)sysdev_create_file (&node->sysdev, &attr_meminfo);sysdev_create_file (&node->sysdev, &attr_numastat);sysdev_create_file (&node->sysdev, &attr_distance); +hugetlb_register_node (node); }return error; }
@@ -169,6 +170,7 @@ void unregister_node(struct node *node)sysdev_remove_file (&node->sysdev, &attr_meminfo);sysdev_remove_file (&node->sysdev, &attr_numastat);sysdev_remove_file (&node->sysdev, &attr_distance); +hugetlb_unregister_node (node);sysdev_unregister (&node->sysdev); }
include/linux/hugetlb.h +11 -0
@@ -6,7 +6,9 @@#ifdef CONFIG_HUGETLB_PAGE #include <linux/mempolicy.h> +#include <linux/node.h> #include <linux/shm.h> +#include <linux/sysdev.h> #include <asm/tlbflush.h> struct ctl_table ;
@@ -26,6 +28,13 @@ void __unmap_hugepage_range(struct vm_area_struct *, unsigned long, unsigned lonint hugetlb_prefault (struct address_space *,struct vm_area_struct *);int hugetlb_report_meminfo (char *);int hugetlb_report_node_meminfo (int ,char *); +#ifdef CONFIG_NUMA +int hugetlb_register_node (struct node *); +void hugetlb_unregister_node (struct node *); +#else +#define hugetlb_register_node (node) do {} while (0) +#define hugetlb_unregister_node (node) do {} while (0) +#endif unsigned long hugetlb_total_pages (void );int hugetlb_fault (struct mm_struct *mm,struct vm_area_struct *vma,unsigned long address,int write_access);
@@ -114,6 +123,8 @@ static inline unsigned long hugetlb_total_pages(void)#define unmap_hugepage_range (vma, start, end) BUG()#define hugetlb_report_meminfo (buf) 0#define hugetlb_report_node_meminfo (n, buf) 0 +#define hugetlb_register_node (node) do {} while (0) +#define hugetlb_unregister_node (node) do {} while (0)#define follow_huge_pmd (mm, addr, pmd, write) NULL#define prepare_hugepage_range (addr,len) (-EINVAL)#define pmd_huge (x) 0
mm/hugetlb.c +118 -4
147 lines not on this page · raw message
--
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 3/3 hugetlb: interleave dequeing of huge pages
In reply to Nishanth AravamudanCurrently, when shrinking the hugetlb pool, we free all of the pages on node 0, then all the pages on node 1, etc. Instead, we interleave over the nodes with memory. If some particularly node should be cleared first, the per-node sysfs attribute can be used for finer-grained control. This also helps with keeping the pool balanced as we change the pool at run-time.
mm/hugetlb.c +35 -4
@@ -84,7 +84,38 @@ static struct page *dequeue_huge_page_node(struct vm_area_struct *vma,return page; } -static struct page *dequeue_huge_page (struct vm_area_struct *vma, +static struct page *dequeue_huge_page (void ) +{ +struct page *page =NULL ; +int start_nid; +int next_nid; + + start_nid = hugetlb_next_nid; + +do { +if (!list_empty (&hugepage_freelists[hugetlb_next_nid])) + page =dequeue_huge_page_node (NULL , hugetlb_next_nid); +/* +* Use a helper variable to find the next node and then +* copy it back to hugetlb_next_nid afterwards: +* otherwise there's a window in which a racer might +* pass invalid nid MAX_NUMNODES to alloc_pages_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. +*/ + next_nid =next_node (hugetlb_next_nid, node_online_map); +if (next_nid ==MAX_NUMNODES ) + next_nid =first_node (node_online_map); + hugetlb_next_nid = next_nid; + }while (!page && hugetlb_next_nid != start_nid); + +return page; +} + +static struct page *dequeue_huge_page_vma (struct vm_area_struct *vma,unsigned long address) {int nid;
@@ -411,7 +442,7 @@ static struct page *alloc_huge_page_shared(struct vm_area_struct *vma,struct page *page;spin_lock (&hugetlb_lock); - page =dequeue_huge_page (vma, addr); + page =dequeue_huge_page_vma (vma, addr);spin_unlock (&hugetlb_lock);return page ? page :ERR_PTR (-VM_FAULT_OOM ); }
@@ -426,7 +457,7 @@ static struct page *alloc_huge_page_private(struct vm_area_struct *vma,spin_lock (&hugetlb_lock);if (free_huge_pages > resv_huge_pages) - page =dequeue_huge_page (vma, addr); + page =dequeue_huge_page_vma (vma, addr);spin_unlock (&hugetlb_lock);if (!page) { page =alloc_buddy_huge_page (vma, addr);
@@ -592,7 +623,7 @@ static unsigned long set_max_huge_pages(unsigned long count) min_count =max (count, min_count);try_to_free_low (min_count);while (min_count < persistent_huge_pages) { -struct page *page =dequeue_huge_page (NULL ,0 ); +struct page *page =dequeue_huge_page ();if (!page)break ;update_and_free_page (page_to_nid (page), page);
--
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/3] hugetlb: add per-node nr_hugepages sysfs attribute
In reply to Nishanth AravamudanQuoted 10 lines · Nishanth Aravamudan
hugetlb: add per-node
nr_hugepagessysfs attributeAllow specifying the number of hugepages to allocate on a particular node. Our current global sysctl will try its best to put hugepages equally on each node, but htat may not always be desired. This allows the admin to control the layout of hugepage allocation at a finer level (while not breaking the existing interface). Add callbacks in the sysfs node registration and unregistration functions into hugetlb to add the
nr_hugepagesattribute, which is a no-op if !NUMA or !HUGETLB.
Quoted 5 lines
Signed-off-by Nishanth Aravamudan <[email protected]>---
Greg, do I need to add documentation for this sysfs attribute toDocumentation/ABI?
Yes, please.
Quoted 3 lines
I'm not sure if I should just add a file in testing/ for just this attribute or should defer and create documentation for all of the
/sys/devices/system/nodeinformation?
How about both for this one, and the existing ones? That would be best.
thanks,
greg k-h
--
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/3] hugetlb: add per-node nr_hugepages sysfs attribute
Quoted 11 lines · Greg KH
Quoted 10 lines · Nishanth Aravamudan
hugetlb: add per-node
nr_hugepagessysfs attributeAllow specifying the number of hugepages to allocate on a particular node. Our current global sysctl will try its best to put hugepages equally on each node, but htat may not always be desired. This allows the admin to control the layout of hugepage allocation at a finer level (while not breaking the existing interface). Add callbacks in the sysfs node registration and unregistration functions into hugetlb to add the
nr_hugepagesattribute, which is a no-op if !NUMA or !HUGETLB.
Quoted 7 lines
Quoted 5 lines
Signed-off-by Nishanth Aravamudan <[email protected]>---
Greg, do I need to add documentation for this sysfs attribute toDocumentation/ABI?Yes, please.
Ok, thanks. I'll submit a follow-on patch.
Quoted 6 lines
Quoted 3 lines
I'm not sure if I should just add a file in testing/ for just this attribute or should defer and create documentation for all of the
/sys/devices/system/nodeinformation?How about both for this one, and the existing ones? That would be best.
Sorry, that's what I meant (documenting existing interface and adding this to that documentation). I'll probably do it in a separate series.
Thanks,
Nish
Signature · 8 lines
Nishanth Aravamudan <[email protected]> IBM Linux Technology Center -- 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>
Quoted 2 lines · Nishanth Aravamudan
hugetlb: numafy several functions
<snip>
Nish: glad to see these surface again. I'll add them [back] into my tree for testing. I'm at 24-mm1. Can't tell from the messages what release they're against, but I'll sort that out.
Another thing: I've tended to test these atop Mel Gorman's zonelist rework and a set of mempolicy cleanups that I'm holding pending acceptance of Mel's patches. I'll probably do that with these. At some point we need to sort out with Andrew when or whether Mel's patches will hit -mm. If so, what order vs yours...
Thanks,
Lee
--
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>
Quoted 9 lines · Lee Schermerhorn
Quoted 2 lines · Nishanth Aravamudan
hugetlb: numafy several functions
<snip>
Nish: glad to see these surface again. I'll add them [back] into my tree for testing. I'm at 24-mm1. Can't tell from the messages what release they're against, but I'll sort that out.
They were against -git tip when I rebased ... hrm that would be 551e4fb2465b87de9d4aa1669b27d624435443bb, I believe.
Quoted 5 lines
Another thing: I've tended to test these atop Mel Gorman's zonelist rework and a set of mempolicy cleanups that I'm holding pending acceptance of Mel's patches. I'll probably do that with these. At some point we need to sort out with Andrew when or whether Mel's patches will hit -mm. If so, what order vs yours...
I think Mel's patches may be more generally useful than mine (as mine are all keyed on hugepage support). So I would like to see his go first then I can rework mine on top, if that is the order that it ends up happening in.
Thanks,
Nish
Signature · 8 lines
Nishanth Aravamudan <[email protected]> IBM Linux Technology Center -- 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>
Quoted 20 lines · Nishanth Aravamudan
Quoted 9 lines · Lee Schermerhorn
Quoted 2 lines · Nishanth Aravamudan
hugetlb: numafy several functions
<snip>
Nish: glad to see these surface again. I'll add them [back] into my tree for testing. I'm at 24-mm1. Can't tell from the messages what release they're against, but I'll sort that out.
They were against -git tip when I rebased ... hrm that would be
551e4fb2465b87de9d4aa1669b27d624435443bb, I believe.Quoted 5 lines
Another thing: I've tended to test these atop Mel Gorman's zonelist rework and a set of mempolicy cleanups that I'm holding pending acceptance of Mel's patches. I'll probably do that with these. At some point we need to sort out with Andrew when or whether Mel's patches will hit -mm. If so, what order vs yours...
Quoted 4 lines
I think Mel's patches may be more generally useful than mine (as mine are all keyed on hugepage support). So I would like to see his go first then I can rework mine on top, if that is the order that it ends up happening in.
Nish:
Heads up: Your "smarter retry" patch will need some rework in vmscan.c because of the memory controller changes [currently in 24-mm1]. I have rebased you patches against 24-mm1, atop Mel's two-zonelist patches and my mempolicy cleanup series. I can send you the entire stack or place the tarball on a web site, if you're interested.
Lee
--
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>
Quoted 26 lines · Lee Schermerhorn
Quoted 20 lines · Nishanth Aravamudan
Quoted 9 lines · Lee Schermerhorn
Quoted 2 lines · Nishanth Aravamudan
hugetlb: numafy several functions
<snip>
Nish: glad to see these surface again. I'll add them [back] into my tree for testing. I'm at 24-mm1. Can't tell from the messages what release they're against, but I'll sort that out.
They were against -git tip when I rebased ... hrm that would be
551e4fb2465b87de9d4aa1669b27d624435443bb, I believe.Quoted 5 lines
Another thing: I've tended to test these atop Mel Gorman's zonelist rework and a set of mempolicy cleanups that I'm holding pending acceptance of Mel's patches. I'll probably do that with these. At some point we need to sort out with Andrew when or whether Mel's patches will hit -mm. If so, what order vs yours...
Quoted 4 lines
I think Mel's patches may be more generally useful than mine (as mine are all keyed on hugepage support). So I would like to see his go first then I can rework mine on top, if that is the order that it ends up happening in.
Quoted 7 lines
Nish:
Heads up: Your "smarter retry" patch will need some rework in
vmscan.cbecause of the memory controller changes [currently in 24-mm1]. I have rebased you patches against 24-mm1, atop Mel's two-zonelist patches and my mempolicy cleanup series. I can send you the entire stack or place the tarball on a web site, if you're interested.
I can refresh the patchset for -mm, I was just posting based upon mainline as that was traditionally how I sent patches to Andrew. But in this case you're right, there are enough collisions with existing -mm bits that I should rebase.
Thanks for the heads up.
-Nish
--
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>
Quoted 21 lines · Nishanth Aravamudan
mm/hugetlb.c +12
-0@@ -141,6 +149,18 @@ static void free_huge_page(struct page *page)* balanced by operating on them in a round-robin fashion. * Returns 1 if an adjustment was made. */ +static int adjust_pool_surplus_node (int delta,int nid) +{ +if (delta <0 && !surplus_huge_pages_node[nid]) +return 0 ; +if (delta >0 && surplus_huge_pages_node[nid] >= + nr_huge_pages_node[nid]) +return 0 ; + surplus_huge_pages += delta; + surplus_huge_pages_node[nid] += delta; +return 1 ; +} +static int adjust_pool_surplus (int delta) {static int prev_nid;@@ -152,19 +172,9 @@ static int adjust_pool_surplus(int delta) nid =next_node (nid, node_online_map);
mm/hugetlb.c static int adjust_pool_surplus(int delta) · line 162
Quoted 10 lines
mm/hugetlb.c +0
-8if (nid ==MAX_NUMNODES ) nid =first_node (node_online_map); - -/* To shrink on this node, there must be a surplus page */ -if (delta <0 && !surplus_huge_pages_node[nid]) -continue ; -/* Surplus cannot exceed the total number of pages */ -if (delta >0 && surplus_huge_pages_node[nid] >= - nr_huge_pages_node[nid]) -continue ;
Unless I am misreading the diff, it seems the above comments were lost in translation. I vote for preserving them :) Otherwise this looks pretty good to me.
Signature · 8 lines
Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center -- 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>
Quoted 28 lines · Adam Litke
Quoted 27 lines · Nishanth Aravamudan
mm/hugetlb.c +12
-4@@ -141,6 +149,18 @@ static void free_huge_page(struct page *page)* balanced by operating on them in a round-robin fashion. * Returns 1 if an adjustment was made. */ +static int adjust_pool_surplus_node (int delta,int nid) +{ +if (delta <0 && !surplus_huge_pages_node[nid]) +return 0 ; +if (delta >0 && surplus_huge_pages_node[nid] >= + nr_huge_pages_node[nid]) +return 0 ; + surplus_huge_pages += delta; + surplus_huge_pages_node[nid] += delta; +return 1 ; +} +static int adjust_pool_surplus (int delta) {static int prev_nid;@@ -152,19 +172,9 @@ static int adjust_pool_surplus(int delta) nid =next_node (nid, node_online_map);if (nid ==MAX_NUMNODES ) nid =first_node (node_online_map); - -/* To shrink on this node, there must be a surplus page */ -if (delta <0 && !surplus_huge_pages_node[nid]) -continue ;
Quoted 8 lines
mm/hugetlb.c static int adjust_pool_surplus(int delta) · line 162
Quoted 4 lines
mm/hugetlb.c +0
-4-/* Surplus cannot exceed the total number of pages */ -if (delta >0 && surplus_huge_pages_node[nid] >= - nr_huge_pages_node[nid]) -continue ;Unless I am misreading the diff, it seems the above comments were lost in translation. I vote for preserving them :) Otherwise this looks pretty good to me.
Oops, sorry about that, Adam. I'll update this in my next posting, pending any other comments/testing feedback.
Thanks,
Nish
--
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>