mm/hugetlb: Get rid of NODEMASK_ALLOC
diff mbox series

Message ID 20190402133415.21983-1-osalvador@suse.de
State New
Headers show
Series
  • mm/hugetlb: Get rid of NODEMASK_ALLOC
Related show

Commit Message

Oscar Salvador April 2, 2019, 1:34 p.m. UTC
NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
first determining whether it should be allocated in the stack or dinamically
depending on NODES_SHIFT.
Right now, it goes the dynamic path whenever the nodemask_t is above 32
bytes.

Although we could bump it to a reasonable value, the largest a nodemask_t
can get is 128 bytes, so since __nr_hugepages_store_common is called from
a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.

This reduces some code churn and complexity.

Signed-off-by: Oscar Salvador <osalvador@suse.de>
---
 mm/hugetlb.c | 36 +++++++++++-------------------------
 1 file changed, 11 insertions(+), 25 deletions(-)

Comments

Mike Kravetz April 2, 2019, 6:37 p.m. UTC | #1
On 4/2/19 6:34 AM, Oscar Salvador wrote:
> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
                                                          ^
> first determining whether it should be allocated in the stack or dinamically
                                                                    ^
> depending on NODES_SHIFT.
> Right now, it goes the dynamic path whenever the nodemask_t is above 32
> bytes.
> 
> Although we could bump it to a reasonable value, the largest a nodemask_t
> can get is 128 bytes, so since __nr_hugepages_store_common is called from
> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
               ^
In addition, the possible call stacks after this routine are not too deep.
Worst case is high order page allocation.

> 
> This reduces some code churn and complexity.
> 
> Signed-off-by: Oscar Salvador <osalvador@suse.de>

Not a huge deal, but a few typos in the commit message.  Thanks for the
clean up.
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Andrew Morton April 2, 2019, 8:01 p.m. UTC | #2
On Tue,  2 Apr 2019 15:34:15 +0200 Oscar Salvador <osalvador@suse.de> wrote:

> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
> first determining whether it should be allocated in the stack or dinamically
> depending on NODES_SHIFT.
> Right now, it goes the dynamic path whenever the nodemask_t is above 32
> bytes.
> 
> Although we could bump it to a reasonable value, the largest a nodemask_t
> can get is 128 bytes, so since __nr_hugepages_store_common is called from
> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
> 
> This reduces some code churn and complexity.

It took a bit of sleuthing to figure out that this patch applies to
Mike's "hugetlbfs: fix potential over/underflow setting node specific
nr_hugepages".  Should they be folded together?  I'm thinking not.

(Also, should "hugetlbfs: fix potential over/underflow setting node
specific nr_hugepages" have been -stableified?  I also think not, but I
bet it happens anyway).
Mike Kravetz April 2, 2019, 8:09 p.m. UTC | #3
On 4/2/19 1:01 PM, Andrew Morton wrote:
> On Tue,  2 Apr 2019 15:34:15 +0200 Oscar Salvador <osalvador@suse.de> wrote:
> 
>> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
>> first determining whether it should be allocated in the stack or dinamically
>> depending on NODES_SHIFT.
>> Right now, it goes the dynamic path whenever the nodemask_t is above 32
>> bytes.
>>
>> Although we could bump it to a reasonable value, the largest a nodemask_t
>> can get is 128 bytes, so since __nr_hugepages_store_common is called from
>> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
>>
>> This reduces some code churn and complexity.
> 
> It took a bit of sleuthing to figure out that this patch applies to
> Mike's "hugetlbfs: fix potential over/underflow setting node specific
> nr_hugepages".  Should they be folded together?  I'm thinking not.

No need to fold.  They are separate issues and that over/underflow patch
may already be doing too many things.

> (Also, should "hugetlbfs: fix potential over/underflow setting node
> specific nr_hugepages" have been -stableified?  I also think not, but I
> bet it happens anyway).

I don't see a great reason for sending to stable.  IIRC, nobody actually
hit this issue: it was found through code inspection.
Oscar Salvador April 2, 2019, 8:16 p.m. UTC | #4
On Tue, 2019-04-02 at 13:01 -0700, Andrew Morton wrote:
> It took a bit of sleuthing to figure out that this patch applies to
> Mike's "hugetlbfs: fix potential over/underflow setting node specific
> nr_hugepages".  Should they be folded together?  I'm thinking not.

Sorry Andrew, I should have mentioned that this patch was based on
Mike's "hugetlb fix potential over/underflow" patch.

Given said that, I would keep the two patches separated, as that one
is a fix, and this one is a cleanup.

> (Also, should "hugetlbfs: fix potential over/underflow setting node
> specific nr_hugepages" have been -stableified?  I also think not, but
> I
> bet it happens anyway).

I am not sure of the consequences in older branches, but if it is not
too much of a hassle, it might be worth? Mike might know better here.
Naoya Horiguchi April 3, 2019, 5:44 a.m. UTC | #5
On Tue, Apr 02, 2019 at 03:34:15PM +0200, Oscar Salvador wrote:
> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
> first determining whether it should be allocated in the stack or dinamically
> depending on NODES_SHIFT.
> Right now, it goes the dynamic path whenever the nodemask_t is above 32
> bytes.
> 
> Although we could bump it to a reasonable value, the largest a nodemask_t
> can get is 128 bytes, so since __nr_hugepages_store_common is called from
> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
> 
> This reduces some code churn and complexity.
> 
> Signed-off-by: Oscar Salvador <osalvador@suse.de>

nice cleanup.

Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Baoquan He April 3, 2019, 7:52 a.m. UTC | #6
On 04/02/19 at 03:34pm, Oscar Salvador wrote:
> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
                                                         ~ and
> first determining whether it should be allocated in the stack or dinamically
                                                              dynamically^^
> depending on NODES_SHIFT.
> Right now, it goes the dynamic path whenever the nodemask_t is above 32
> bytes.
> 
> Although we could bump it to a reasonable value, the largest a nodemask_t
> can get is 128 bytes, so since __nr_hugepages_store_common is called from
> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here.
> 
> This reduces some code churn and complexity.
> 
> Signed-off-by: Oscar Salvador <osalvador@suse.de>
> ---
>  mm/hugetlb.c | 36 +++++++++++-------------------------
>  1 file changed, 11 insertions(+), 25 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index f79ae4e42159..9cb2f91af897 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2447,44 +2447,30 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
>  					   unsigned long count, size_t len)
>  {
>  	int err;
> -	NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
> +	nodemask_t nodes_allowed, *n_mask;
>  
> -	if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) {
> -		err = -EINVAL;
> -		goto out;
> -	}
> +	if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
> +		return -EINVAL;
>  
>  	if (nid == NUMA_NO_NODE) {
>  		/*
>  		 * global hstate attribute
>  		 */
>  		if (!(obey_mempolicy &&
> -				init_nodemask_of_mempolicy(nodes_allowed))) {
> -			NODEMASK_FREE(nodes_allowed);
> -			nodes_allowed = &node_states[N_MEMORY];
> -		}
> -	} else if (nodes_allowed) {
> +				init_nodemask_of_mempolicy(&nodes_allowed)))
> +			n_mask = &node_states[N_MEMORY];
> +		else
> +			n_mask = &nodes_allowed;
> +	} else {
>  		/*
>  		 * Node specific request.  count adjustment happens in
>  		 * set_max_huge_pages() after acquiring hugetlb_lock.
>  		 */
> -		init_nodemask_of_node(nodes_allowed, nid);
> -	} else {
> -		/*
> -		 * Node specific request, but we could not allocate the few
> -		 * words required for a node mask.  We are unlikely to hit
> -		 * this condition.  Since we can not pass down the appropriate
> -		 * node mask, just return ENOMEM.
> -		 */
> -		err = -ENOMEM;
> -		goto out;
> +		init_nodemask_of_node(&nodes_allowed, nid);
> +		n_mask = &nodes_allowed;
>  	}
>  
> -	err = set_max_huge_pages(h, count, nid, nodes_allowed);
> -
> -out:
> -	if (nodes_allowed != &node_states[N_MEMORY])
> -		NODEMASK_FREE(nodes_allowed);
> +	err = set_max_huge_pages(h, count, nid, n_mask);
>  
>  	return err ? err : len;
>  }
> -- 
> 2.13.7
>

Patch
diff mbox series

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index f79ae4e42159..9cb2f91af897 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2447,44 +2447,30 @@  static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
 					   unsigned long count, size_t len)
 {
 	int err;
-	NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
+	nodemask_t nodes_allowed, *n_mask;
 
-	if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) {
-		err = -EINVAL;
-		goto out;
-	}
+	if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
+		return -EINVAL;
 
 	if (nid == NUMA_NO_NODE) {
 		/*
 		 * global hstate attribute
 		 */
 		if (!(obey_mempolicy &&
-				init_nodemask_of_mempolicy(nodes_allowed))) {
-			NODEMASK_FREE(nodes_allowed);
-			nodes_allowed = &node_states[N_MEMORY];
-		}
-	} else if (nodes_allowed) {
+				init_nodemask_of_mempolicy(&nodes_allowed)))
+			n_mask = &node_states[N_MEMORY];
+		else
+			n_mask = &nodes_allowed;
+	} else {
 		/*
 		 * Node specific request.  count adjustment happens in
 		 * set_max_huge_pages() after acquiring hugetlb_lock.
 		 */
-		init_nodemask_of_node(nodes_allowed, nid);
-	} else {
-		/*
-		 * Node specific request, but we could not allocate the few
-		 * words required for a node mask.  We are unlikely to hit
-		 * this condition.  Since we can not pass down the appropriate
-		 * node mask, just return ENOMEM.
-		 */
-		err = -ENOMEM;
-		goto out;
+		init_nodemask_of_node(&nodes_allowed, nid);
+		n_mask = &nodes_allowed;
 	}
 
-	err = set_max_huge_pages(h, count, nid, nodes_allowed);
-
-out:
-	if (nodes_allowed != &node_states[N_MEMORY])
-		NODEMASK_FREE(nodes_allowed);
+	err = set_max_huge_pages(h, count, nid, n_mask);
 
 	return err ? err : len;
 }