[PATCH] mm/sparse: return right away if sparsemap_buf is null

[PATCH] mm/sparse: return right away if sparsemap_buf is null

[Leesoo Ahn]

sparse_buffer_fini(..) takes the following actions even though the value of
sparsemap_buf is NULL,
1. calculate size of sparsemap buffer (which is meaningless).
2. set sparsemap_buf variable to NULL (although it is already NULL).

These steps are unnecessary if the variable, sparsemap_buf is NULL.

Refactor the function to return right away if the variable is NULL.
Hence, it doesn't need to take further actions.

Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
---
 mm/sparse.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/mm/sparse.c b/mm/sparse.c
index e4b830091d13..091e4bc2f72c 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -469,9 +469,13 @@ static void __init sparse_buffer_init(unsigned long size, int nid)
 
 static void __init sparse_buffer_fini(void)
 {
-	unsigned long size = sparsemap_buf_end - sparsemap_buf;
+	unsigned long size;
 
-	if (sparsemap_buf && size > 0)
+	if (!sparsemap_buf)
+		return;
+
+	size = sparsemap_buf_end - sparsemap_buf;
+	if (size > 0)
 		sparse_buffer_free(size);
 	sparsemap_buf = NULL;
 }
-- 
2.34.1

Re: [PATCH] mm/sparse: return right away if sparsemap_buf is null

[Mike Rapoport]

On Fri, Jul 26, 2024 at 04:10:23PM +0900, Leesoo Ahn wrote:
> sparse_buffer_fini(..) takes the following actions even though the value of
> sparsemap_buf is NULL,
> 1. calculate size of sparsemap buffer (which is meaningless).
> 2. set sparsemap_buf variable to NULL (although it is already NULL).
> 
> These steps are unnecessary if the variable, sparsemap_buf is NULL.
> 
> Refactor the function to return right away if the variable is NULL.
> Hence, it doesn't need to take further actions.

sparse_buffer_fini() is called a few times on init so saving a jump (if at
all) does not worth the churn.
 
> Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
> ---
>  mm/sparse.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/sparse.c b/mm/sparse.c
> index e4b830091d13..091e4bc2f72c 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -469,9 +469,13 @@ static void __init sparse_buffer_init(unsigned long size, int nid)
>  
>  static void __init sparse_buffer_fini(void)
>  {
> -	unsigned long size = sparsemap_buf_end - sparsemap_buf;
> +	unsigned long size;
>  
> -	if (sparsemap_buf && size > 0)
> +	if (!sparsemap_buf)
> +		return;
> +
> +	size = sparsemap_buf_end - sparsemap_buf;
> +	if (size > 0)
>  		sparse_buffer_free(size);
>  	sparsemap_buf = NULL;
>  }
> -- 
> 2.34.1
> 
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH] mm/sparse: return right away if sparsemap_buf is null

[Anshuman Khandual]

On 7/28/24 18:13, Mike Rapoport wrote:
> On Fri, Jul 26, 2024 at 04:10:23PM +0900, Leesoo Ahn wrote:
>> sparse_buffer_fini(..) takes the following actions even though the value of
>> sparsemap_buf is NULL,
>> 1. calculate size of sparsemap buffer (which is meaningless).
>> 2. set sparsemap_buf variable to NULL (although it is already NULL).
>>
>> These steps are unnecessary if the variable, sparsemap_buf is NULL.
>>
>> Refactor the function to return right away if the variable is NULL.
>> Hence, it doesn't need to take further actions.
> 
> sparse_buffer_fini() is called a few times on init so saving a jump (if at
> all) does not worth the churn.

Agreed, this is not worth the churn given there could be just a single
call instance for sparse_buffer_fini(), either in normal or error path
in sparse_init_nid().

>  
>> Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
>> ---
>>  mm/sparse.c | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/sparse.c b/mm/sparse.c
>> index e4b830091d13..091e4bc2f72c 100644
>> --- a/mm/sparse.c
>> +++ b/mm/sparse.c
>> @@ -469,9 +469,13 @@ static void __init sparse_buffer_init(unsigned long size, int nid)
>>  
>>  static void __init sparse_buffer_fini(void)
>>  {
>> -	unsigned long size = sparsemap_buf_end - sparsemap_buf;
>> +	unsigned long size;
>>  
>> -	if (sparsemap_buf && size > 0)
>> +	if (!sparsemap_buf)
>> +		return;
>> +
>> +	size = sparsemap_buf_end - sparsemap_buf;
>> +	if (size > 0)
>>  		sparse_buffer_free(size);
>>  	sparsemap_buf = NULL;
>>  }
>> -- 
>> 2.34.1
>>
>>
> 

Re: [PATCH] mm/sparse: return right away if sparsemap_buf is null

[Leesoo Ahn]

2024년 7월 28일 (일) 오후 9:43, Mike Rapoport <rppt@kernel.org>님이 작성:
>
> On Fri, Jul 26, 2024 at 04:10:23PM +0900, Leesoo Ahn wrote:
> > sparse_buffer_fini(..) takes the following actions even though the value of
> > sparsemap_buf is NULL,
> > 1. calculate size of sparsemap buffer (which is meaningless).
> > 2. set sparsemap_buf variable to NULL (although it is already NULL).
> >
> > These steps are unnecessary if the variable, sparsemap_buf is NULL.
> >
> > Refactor the function to return right away if the variable is NULL.
> > Hence, it doesn't need to take further actions.
>
> sparse_buffer_fini() is called a few times on init so saving a jump (if at
> all) does not worth the churn.

Fair enough.

Any related to refactoring codebase will be unlikely to be taken into upstream??

BR,
Leesoo

Re: [PATCH] mm/sparse: return right away if sparsemap_buf is null

[David Hildenbrand]

On 07.08.24 05:21, Leesoo Ahn wrote:
> 2024년 7월 28일 (일) 오후 9:43, Mike Rapoport <rppt@kernel.org>님이 작성:
>>
>> On Fri, Jul 26, 2024 at 04:10:23PM +0900, Leesoo Ahn wrote:
>>> sparse_buffer_fini(..) takes the following actions even though the value of
>>> sparsemap_buf is NULL,
>>> 1. calculate size of sparsemap buffer (which is meaningless).
>>> 2. set sparsemap_buf variable to NULL (although it is already NULL).
>>>
>>> These steps are unnecessary if the variable, sparsemap_buf is NULL.
>>>
>>> Refactor the function to return right away if the variable is NULL.
>>> Hence, it doesn't need to take further actions.
>>
>> sparse_buffer_fini() is called a few times on init so saving a jump (if at
>> all) does not worth the churn.
> 
> Fair enough.
> 
> Any related to refactoring codebase will be unlikely to be taken into upstream??

Any reasonable cleanups or reasonable optimizations are welcome.

Micro-optimizations that effectively add code/LOC, not so much :)

-- 
Cheers,

David / dhildenb