Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1576604 > unrolled thread
| Started by | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| First post | 2017-02-08 15:10 +0100 |
| Last post | 2017-02-08 18:40 +0100 |
| Articles | 8 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH 0/3] Define coherent device memory node Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-02-08 15:10 +0100
Re: [PATCH 0/3] Define coherent device memory node Balbir Singh <bsingharora@gmail.com> - 2017-02-08 17:50 +0100
[PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-02-08 18:30 +0100
Re: [PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes Vlastimil Babka <vbabka@suse.cz> - 2017-02-08 18:30 +0100
Re: [PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-02-09 07:10 +0100
Re: [PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes Vlastimil Babka <vbabka@suse.cz> - 2017-02-09 09:50 +0100
Re: [PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-02-09 13:00 +0100
[PATCH 2/3] mm: Enable HugeTLB allocation isolation for CDM nodes Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-02-08 18:40 +0100
| From | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-02-08 15:10 +0100 |
| Subject | [PATCH 0/3] Define coherent device memory node |
| Message-ID | <t8B6y-1k4-19@gated-at.bofh.it> |
This three patches define CDM node with HugeTLB & Buddy allocation isolation. Please refer to the last RFC posting mentioned here for details. The series has been split for easier review process. The next part of the work like VM flags, auto NUMA and KSM interactions with tagged VMAs will follow later. https://lkml.org/lkml/2017/1/29/198 Optional Buddy allocation isolation methods (1) GFP flag based (mm_cdm_v1_optional_gfp) (2) Zonelist rebuilding (mm_cdm_v1_optional_zonelist) (3) Cpuset (mm_cdm_v1_optional_cpusets) All of these optional methods as well as the posted nodemask (mm_cdm_v1) approach can be accessed from the following git tree. https://github.com/akhandual/linux.git Anshuman Khandual (3): mm: Define coherent device memory (CDM) node mm: Enable HugeTLB allocation isolation for CDM nodes mm: Enable Buddy allocation isolation for CDM nodes Documentation/ABI/stable/sysfs-devices-node | 7 +++++ arch/powerpc/Kconfig | 1 + arch/powerpc/mm/numa.c | 7 +++++ drivers/base/node.c | 6 ++++ include/linux/node.h | 49 +++++++++++++++++++++++++++++ include/linux/nodemask.h | 3 ++ mm/Kconfig | 4 +++ mm/hugetlb.c | 25 +++++++++------ mm/memory_hotplug.c | 10 ++++++ mm/page_alloc.c | 33 +++++++++++++++++-- 10 files changed, 134 insertions(+), 11 deletions(-) -- 2.9.3
[toc] | [next] | [standalone]
| From | Balbir Singh <bsingharora@gmail.com> |
|---|---|
| Date | 2017-02-08 17:50 +0100 |
| Message-ID | <t8DBn-2Hv-1@gated-at.bofh.it> |
| In reply to | #1576604 |
On 02/08/2017 07:31 PM, Anshuman Khandual wrote: > This three patches define CDM node with HugeTLB & Buddy allocation > isolation. Please refer to the last RFC posting mentioned here for details. > The series has been split for easier review process. The next part of the > work like VM flags, auto NUMA and KSM interactions with tagged VMAs will > follow later. > > https://lkml.org/lkml/2017/1/29/198 > > Optional Buddy allocation isolation methods > > (1) GFP flag based (mm_cdm_v1_optional_gfp) > (2) Zonelist rebuilding (mm_cdm_v1_optional_zonelist) > (3) Cpuset (mm_cdm_v1_optional_cpusets) > > All of these optional methods as well as the posted nodemask (mm_cdm_v1) > approach can be accessed from the following git tree. > Definitely much better looking, in general I like the approach and would ack it. Lets stick to mm_cdm_v1 (this post) as a starting point Balbir Singh.
[toc] | [prev] | [next] | [standalone]
| From | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-02-08 18:30 +0100 |
| Subject | [PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes |
| Message-ID | <t8Ee5-3aO-11@gated-at.bofh.it> |
| In reply to | #1576604 |
This implements allocation isolation for CDM nodes in buddy allocator by
discarding CDM memory zones all the time except in the cases where the gfp
flag has got __GFP_THISNODE or the nodemask contains CDM nodes in cases
where it is non NULL (explicit allocation request in the kernel or user
process MPOL_BIND policy based requests).
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
mm/page_alloc.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 40908de..7d8c82a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -64,6 +64,7 @@
#include <linux/page_owner.h>
#include <linux/kthread.h>
#include <linux/memcontrol.h>
+#include <linux/node.h>
#include <asm/sections.h>
#include <asm/tlbflush.h>
@@ -2908,6 +2909,24 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
struct page *page;
unsigned long mark;
+ /*
+ * CDM nodes get skipped if the requested gfp flag
+ * does not have __GFP_THISNODE set or the nodemask
+ * does not have any CDM nodes in case the nodemask
+ * is non NULL (explicit allocation requests from
+ * kernel or user process MPOL_BIND policy which has
+ * CDM nodes).
+ */
+ if (is_cdm_node(zone->zone_pgdat->node_id)) {
+ if (!(gfp_mask & __GFP_THISNODE)) {
+ if (!ac->nodemask)
+ continue;
+
+ if (!nodemask_has_cdm(*ac->nodemask))
+ continue;
+ }
+ }
+
if (cpusets_enabled() &&
(alloc_flags & ALLOC_CPUSET) &&
!__cpuset_zone_allowed(zone, gfp_mask))
--
2.9.3
[toc] | [prev] | [next] | [standalone]
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2017-02-08 18:30 +0100 |
| Subject | Re: [PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes |
| Message-ID | <t8Ee6-3aO-13@gated-at.bofh.it> |
| In reply to | #1576743 |
On 02/08/2017 03:01 PM, Anshuman Khandual wrote:
> This implements allocation isolation for CDM nodes in buddy allocator by
> discarding CDM memory zones all the time except in the cases where the gfp
> flag has got __GFP_THISNODE or the nodemask contains CDM nodes in cases
> where it is non NULL (explicit allocation request in the kernel or user
> process MPOL_BIND policy based requests).
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
> mm/page_alloc.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 40908de..7d8c82a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -64,6 +64,7 @@
> #include <linux/page_owner.h>
> #include <linux/kthread.h>
> #include <linux/memcontrol.h>
> +#include <linux/node.h>
>
> #include <asm/sections.h>
> #include <asm/tlbflush.h>
> @@ -2908,6 +2909,24 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
> struct page *page;
> unsigned long mark;
>
> + /*
> + * CDM nodes get skipped if the requested gfp flag
> + * does not have __GFP_THISNODE set or the nodemask
> + * does not have any CDM nodes in case the nodemask
> + * is non NULL (explicit allocation requests from
> + * kernel or user process MPOL_BIND policy which has
> + * CDM nodes).
> + */
> + if (is_cdm_node(zone->zone_pgdat->node_id)) {
> + if (!(gfp_mask & __GFP_THISNODE)) {
> + if (!ac->nodemask)
> + continue;
> +
> + if (!nodemask_has_cdm(*ac->nodemask))
> + continue;
nodemask_has_cdm() looks quite expensive, combined with the loop here that's
O(n^2). But I don't understand why you need it. If there is no cdm node in the
nodemask, then we never reach this code with a cdm node, because the zonelist
iterator already checks the nodemask? Am I missing something?
> + }
> + }
> +
> if (cpusets_enabled() &&
> (alloc_flags & ALLOC_CPUSET) &&
> !__cpuset_zone_allowed(zone, gfp_mask))
>
[toc] | [prev] | [next] | [standalone]
| From | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-02-09 07:10 +0100 |
| Subject | Re: [PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes |
| Message-ID | <t8Q5z-2kK-1@gated-at.bofh.it> |
| In reply to | #1576745 |
On 02/08/2017 10:48 PM, Vlastimil Babka wrote:
> On 02/08/2017 03:01 PM, Anshuman Khandual wrote:
>> This implements allocation isolation for CDM nodes in buddy allocator by
>> discarding CDM memory zones all the time except in the cases where the
>> gfp
>> flag has got __GFP_THISNODE or the nodemask contains CDM nodes in cases
>> where it is non NULL (explicit allocation request in the kernel or user
>> process MPOL_BIND policy based requests).
>>
>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>> ---
>> mm/page_alloc.c | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 40908de..7d8c82a 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -64,6 +64,7 @@
>> #include <linux/page_owner.h>
>> #include <linux/kthread.h>
>> #include <linux/memcontrol.h>
>> +#include <linux/node.h>
>>
>> #include <asm/sections.h>
>> #include <asm/tlbflush.h>
>> @@ -2908,6 +2909,24 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned
>> int order, int alloc_flags,
>> struct page *page;
>> unsigned long mark;
>>
>> + /*
>> + * CDM nodes get skipped if the requested gfp flag
>> + * does not have __GFP_THISNODE set or the nodemask
>> + * does not have any CDM nodes in case the nodemask
>> + * is non NULL (explicit allocation requests from
>> + * kernel or user process MPOL_BIND policy which has
>> + * CDM nodes).
>> + */
>> + if (is_cdm_node(zone->zone_pgdat->node_id)) {
>> + if (!(gfp_mask & __GFP_THISNODE)) {
>> + if (!ac->nodemask)
>> + continue;
>> +
>> + if (!nodemask_has_cdm(*ac->nodemask))
>> + continue;
>
> nodemask_has_cdm() looks quite expensive, combined with the loop here
> that's O(n^2). But I don't understand why you need it. If there is no
> cdm node in the nodemask, then we never reach this code with a cdm node,
> because the zonelist iterator already checks the nodemask? Am I missing
> something?
A CDM zone can be selected during zonelist iteration if
(1) If nodemask is NULL (where all zones are eligible)
(1) Skip it if __GFP_THISNODE is not mentioned
(2) Pick it if __GFP_THISNODE is mentioned
(2) If nodemask has CDM (where CDM zones are eligible)
(1) Pick it if nodemask has CDM
(2) Pick it if __GFP_THISNODE is mentioned
(1) (1) Enforces the primary isolation
(2) (1) Is the only option which could be O(n^2) as the worst case
Checking for both the zone being a CDM zone and the nodemask containing
CDM node has to happen together for (2) (1). But we dont run into this
option unless we have first checked if request contains __GFP_THISNODE
and that nodemask is really a non NULL value. Hence the number cases
getting into (2) (1) should be less. IIUC only the user space MPOL_BIND
ones will come here.
[toc] | [prev] | [next] | [standalone]
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2017-02-09 09:50 +0100 |
| Subject | Re: [PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes |
| Message-ID | <t8SAp-3UH-7@gated-at.bofh.it> |
| In reply to | #1577325 |
On 02/09/2017 06:05 AM, Anshuman Khandual wrote:
> On 02/08/2017 10:48 PM, Vlastimil Babka wrote:
>> On 02/08/2017 03:01 PM, Anshuman Khandual wrote:
>>> This implements allocation isolation for CDM nodes in buddy allocator by
>>> discarding CDM memory zones all the time except in the cases where the
>>> gfp
>>> flag has got __GFP_THISNODE or the nodemask contains CDM nodes in cases
>>> where it is non NULL (explicit allocation request in the kernel or user
>>> process MPOL_BIND policy based requests).
>>>
>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>> ---
>>> mm/page_alloc.c | 19 +++++++++++++++++++
>>> 1 file changed, 19 insertions(+)
>>>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index 40908de..7d8c82a 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -64,6 +64,7 @@
>>> #include <linux/page_owner.h>
>>> #include <linux/kthread.h>
>>> #include <linux/memcontrol.h>
>>> +#include <linux/node.h>
>>>
>>> #include <asm/sections.h>
>>> #include <asm/tlbflush.h>
>>> @@ -2908,6 +2909,24 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned
>>> int order, int alloc_flags,
>>> struct page *page;
>>> unsigned long mark;
>>>
>>> + /*
>>> + * CDM nodes get skipped if the requested gfp flag
>>> + * does not have __GFP_THISNODE set or the nodemask
>>> + * does not have any CDM nodes in case the nodemask
>>> + * is non NULL (explicit allocation requests from
>>> + * kernel or user process MPOL_BIND policy which has
>>> + * CDM nodes).
>>> + */
>>> + if (is_cdm_node(zone->zone_pgdat->node_id)) {
>>> + if (!(gfp_mask & __GFP_THISNODE)) {
>>> + if (!ac->nodemask)
>>> + continue;
>>> +
>>> + if (!nodemask_has_cdm(*ac->nodemask))
>>> + continue;
>>
>> nodemask_has_cdm() looks quite expensive, combined with the loop here
>> that's O(n^2). But I don't understand why you need it. If there is no
>> cdm node in the nodemask, then we never reach this code with a cdm node,
>> because the zonelist iterator already checks the nodemask? Am I missing
>> something?
>
> A CDM zone can be selected during zonelist iteration if
>
> (1) If nodemask is NULL (where all zones are eligible)
>
> (1) Skip it if __GFP_THISNODE is not mentioned
> (2) Pick it if __GFP_THISNODE is mentioned
>
> (2) If nodemask has CDM (where CDM zones are eligible)
>
> (1) Pick it if nodemask has CDM
> (2) Pick it if __GFP_THISNODE is mentioned
>
> (1) (1) Enforces the primary isolation
> (2) (1) Is the only option which could be O(n^2) as the worst case
>
> Checking for both the zone being a CDM zone and the nodemask containing
> CDM node has to happen together for (2) (1). But we dont run into this
> option unless we have first checked if request contains __GFP_THISNODE
> and that nodemask is really a non NULL value. Hence the number cases
> getting into (2) (1) should be less. IIUC only the user space MPOL_BIND
> ones will come here.
Maybe I'm still missing something, but when you do nodemask_has_cdm() above then
we already passed "if (!ac->nodemask) continue" which means ac->nodemask is not
null, which means the zonelist iterator already did the filtering on
ac->nodemask, and if this zone passed the filter and it's a cdm zone, then it
has to be set in the nodemask?
[toc] | [prev] | [next] | [standalone]
| From | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-02-09 13:00 +0100 |
| Subject | Re: [PATCH 3/3] mm: Enable Buddy allocation isolation for CDM nodes |
| Message-ID | <t8Vyi-5Gs-15@gated-at.bofh.it> |
| In reply to | #1577375 |
On 02/09/2017 02:18 PM, Vlastimil Babka wrote:
> On 02/09/2017 06:05 AM, Anshuman Khandual wrote:
>> On 02/08/2017 10:48 PM, Vlastimil Babka wrote:
>>> On 02/08/2017 03:01 PM, Anshuman Khandual wrote:
>>>> This implements allocation isolation for CDM nodes in buddy
>>>> allocator by
>>>> discarding CDM memory zones all the time except in the cases where the
>>>> gfp
>>>> flag has got __GFP_THISNODE or the nodemask contains CDM nodes in cases
>>>> where it is non NULL (explicit allocation request in the kernel or user
>>>> process MPOL_BIND policy based requests).
>>>>
>>>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>>> ---
>>>> mm/page_alloc.c | 19 +++++++++++++++++++
>>>> 1 file changed, 19 insertions(+)
>>>>
>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>> index 40908de..7d8c82a 100644
>>>> --- a/mm/page_alloc.c
>>>> +++ b/mm/page_alloc.c
>>>> @@ -64,6 +64,7 @@
>>>> #include <linux/page_owner.h>
>>>> #include <linux/kthread.h>
>>>> #include <linux/memcontrol.h>
>>>> +#include <linux/node.h>
>>>>
>>>> #include <asm/sections.h>
>>>> #include <asm/tlbflush.h>
>>>> @@ -2908,6 +2909,24 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned
>>>> int order, int alloc_flags,
>>>> struct page *page;
>>>> unsigned long mark;
>>>>
>>>> + /*
>>>> + * CDM nodes get skipped if the requested gfp flag
>>>> + * does not have __GFP_THISNODE set or the nodemask
>>>> + * does not have any CDM nodes in case the nodemask
>>>> + * is non NULL (explicit allocation requests from
>>>> + * kernel or user process MPOL_BIND policy which has
>>>> + * CDM nodes).
>>>> + */
>>>> + if (is_cdm_node(zone->zone_pgdat->node_id)) {
>>>> + if (!(gfp_mask & __GFP_THISNODE)) {
>>>> + if (!ac->nodemask)
>>>> + continue;
>>>> +
>>>> + if (!nodemask_has_cdm(*ac->nodemask))
>>>> + continue;
>>>
>>> nodemask_has_cdm() looks quite expensive, combined with the loop here
>>> that's O(n^2). But I don't understand why you need it. If there is no
>>> cdm node in the nodemask, then we never reach this code with a cdm node,
>>> because the zonelist iterator already checks the nodemask? Am I missing
>>> something?
>>
>> A CDM zone can be selected during zonelist iteration if
>>
>> (1) If nodemask is NULL (where all zones are eligible)
>>
>> (1) Skip it if __GFP_THISNODE is not mentioned
>> (2) Pick it if __GFP_THISNODE is mentioned
>>
>> (2) If nodemask has CDM (where CDM zones are eligible)
>>
>> (1) Pick it if nodemask has CDM
>> (2) Pick it if __GFP_THISNODE is mentioned
>>
>> (1) (1) Enforces the primary isolation
>> (2) (1) Is the only option which could be O(n^2) as the worst case
>>
>> Checking for both the zone being a CDM zone and the nodemask containing
>> CDM node has to happen together for (2) (1). But we dont run into this
>> option unless we have first checked if request contains __GFP_THISNODE
>> and that nodemask is really a non NULL value. Hence the number cases
>> getting into (2) (1) should be less. IIUC only the user space MPOL_BIND
>> ones will come here.
>
> Maybe I'm still missing something, but when you do nodemask_has_cdm()
> above then we already passed "if (!ac->nodemask) continue" which means
> ac->nodemask is not null, which means the zonelist iterator already did
> the filtering on ac->nodemask, and if this zone passed the filter and
> it's a cdm zone, then it has to be set in the nodemask?
Hmm, think you are right. Then I can drop the last check there. Will test
it out. Thanks for pointing this out.
[toc] | [prev] | [next] | [standalone]
| From | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-02-08 18:40 +0100 |
| Subject | [PATCH 2/3] mm: Enable HugeTLB allocation isolation for CDM nodes |
| Message-ID | <t8EnN-3ey-39@gated-at.bofh.it> |
| In reply to | #1576604 |
HugeTLB allocation/release/accounting currently spans across all the nodes
under N_MEMORY node mask. Coherent memory nodes should not be part of these
allocations. So use system_mem_nodemask() call to fetch system RAM only
nodes on the platform which can then be used for HugeTLB allocation purpose
instead of N_MEMORY node mask. This isolates coherent device memory nodes
from HugeTLB allocations.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
mm/hugetlb.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c7025c1..9a46d9f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1790,6 +1790,7 @@ static void return_unused_surplus_pages(struct hstate *h,
unsigned long unused_resv_pages)
{
unsigned long nr_pages;
+ nodemask_t system_mem = system_mem_nodemask();
/* Cannot return gigantic pages currently */
if (hstate_is_gigantic(h))
@@ -1816,7 +1817,7 @@ static void return_unused_surplus_pages(struct hstate *h,
while (nr_pages--) {
h->resv_huge_pages--;
unused_resv_pages--;
- if (!free_pool_huge_page(h, &node_states[N_MEMORY], 1))
+ if (!free_pool_huge_page(h, &system_mem, 1))
goto out;
cond_resched_lock(&hugetlb_lock);
}
@@ -2107,8 +2108,9 @@ int __weak alloc_bootmem_huge_page(struct hstate *h)
{
struct huge_bootmem_page *m;
int nr_nodes, node;
+ nodemask_t system_mem = system_mem_nodemask();
- for_each_node_mask_to_alloc(h, nr_nodes, node, &node_states[N_MEMORY]) {
+ for_each_node_mask_to_alloc(h, nr_nodes, node, &system_mem) {
void *addr;
addr = memblock_virt_alloc_try_nid_nopanic(
@@ -2177,13 +2179,14 @@ static void __init gather_bootmem_prealloc(void)
static void __init hugetlb_hstate_alloc_pages(struct hstate *h)
{
unsigned long i;
+ nodemask_t system_mem = system_mem_nodemask();
+
for (i = 0; i < h->max_huge_pages; ++i) {
if (hstate_is_gigantic(h)) {
if (!alloc_bootmem_huge_page(h))
break;
- } else if (!alloc_fresh_huge_page(h,
- &node_states[N_MEMORY]))
+ } else if (!alloc_fresh_huge_page(h, &system_mem))
break;
}
h->max_huge_pages = i;
@@ -2420,6 +2423,8 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
unsigned long count, size_t len)
{
int err;
+ nodemask_t system_mem = system_mem_nodemask();
+
NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
if (hstate_is_gigantic(h) && !gigantic_page_supported()) {
@@ -2434,7 +2439,7 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
if (!(obey_mempolicy &&
init_nodemask_of_mempolicy(nodes_allowed))) {
NODEMASK_FREE(nodes_allowed);
- nodes_allowed = &node_states[N_MEMORY];
+ nodes_allowed = &system_mem;
}
} else if (nodes_allowed) {
/*
@@ -2444,11 +2449,11 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
count += h->nr_huge_pages - h->nr_huge_pages_node[nid];
init_nodemask_of_node(nodes_allowed, nid);
} else
- nodes_allowed = &node_states[N_MEMORY];
+ nodes_allowed = &system_mem;
h->max_huge_pages = set_max_huge_pages(h, count, nodes_allowed);
- if (nodes_allowed != &node_states[N_MEMORY])
+ if (nodes_allowed != &system_mem)
NODEMASK_FREE(nodes_allowed);
return len;
@@ -2745,9 +2750,10 @@ static void hugetlb_register_node(struct node *node)
*/
static void __init hugetlb_register_all_nodes(void)
{
+ nodemask_t nodes = system_mem_nodemask();
int nid;
- for_each_node_state(nid, N_MEMORY) {
+ for_each_node_mask(nid, nodes) {
struct node *node = node_devices[nid];
if (node->dev.id == nid)
hugetlb_register_node(node);
@@ -3019,11 +3025,12 @@ void hugetlb_show_meminfo(void)
{
struct hstate *h;
int nid;
+ nodemask_t system_mem = system_mem_nodemask();
if (!hugepages_supported())
return;
- for_each_node_state(nid, N_MEMORY)
+ for_each_node_mask(nid, system_mem)
for_each_hstate(h)
pr_info("Node %d hugepages_total=%u hugepages_free=%u hugepages_surp=%u hugepages_size=%lukB\n",
nid,
--
2.9.3
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web