Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1705847 > unrolled thread

[v6 14/15] mm: optimize early system hash allocations

Started byPavel Tatashin <pasha.tatashin@oracle.com>
First post2017-08-07 22:50 +0200
Last post2017-08-11 18:20 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [v6 14/15] mm: optimize early system hash allocations Pavel Tatashin <pasha.tatashin@oracle.com> - 2017-08-07 22:50 +0200
    Re: [v6 14/15] mm: optimize early system hash allocations Michal Hocko <mhocko@kernel.org> - 2017-08-11 15:10 +0200
      Re: [v6 14/15] mm: optimize early system hash allocations Pasha Tatashin <pasha.tatashin@oracle.com> - 2017-08-11 18:20 +0200

#1705847 — [v6 14/15] mm: optimize early system hash allocations

FromPavel Tatashin <pasha.tatashin@oracle.com>
Date2017-08-07 22:50 +0200
Subject[v6 14/15] mm: optimize early system hash allocations
Message-ID<ubX8n-5vB-31@gated-at.bofh.it>
Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify
that memory that was allocated for system hash needs to be zeroed,
otherwise the memory does not need to be zeroed, and client will initialize
it.

If memory does not need to be zero'd, call the new
memblock_virt_alloc_raw() interface, and thus improve the boot performance.

Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Reviewed-by: Bob Picco <bob.picco@oracle.com>
---
 mm/page_alloc.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4d32c1fa4c6c..000806298dfb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7354,18 +7354,17 @@ void *__init alloc_large_system_hash(const char *tablename,
 
 	log2qty = ilog2(numentries);
 
-	/*
-	 * memblock allocator returns zeroed memory already, so HASH_ZERO is
-	 * currently not used when HASH_EARLY is specified.
-	 */
 	gfp_flags = (flags & HASH_ZERO) ? GFP_ATOMIC | __GFP_ZERO : GFP_ATOMIC;
 	do {
 		size = bucketsize << log2qty;
-		if (flags & HASH_EARLY)
-			table = memblock_virt_alloc_nopanic(size, 0);
-		else if (hashdist)
+		if (flags & HASH_EARLY) {
+			if (flags & HASH_ZERO)
+				table = memblock_virt_alloc_nopanic(size, 0);
+			else
+				table = memblock_virt_alloc_raw(size, 0);
+		} else if (hashdist) {
 			table = __vmalloc(size, gfp_flags, PAGE_KERNEL);
-		else {
+		} else {
 			/*
 			 * If bucketsize is not a power-of-two, we may free
 			 * some pages at the end of hash table which
-- 
2.14.0

[toc] | [next] | [standalone]


#1709587

FromMichal Hocko <mhocko@kernel.org>
Date2017-08-11 15:10 +0200
Message-ID<udhRn-3Vr-5@gated-at.bofh.it>
In reply to#1705847
On Mon 07-08-17 16:38:48, Pavel Tatashin wrote:
> Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify
> that memory that was allocated for system hash needs to be zeroed,
> otherwise the memory does not need to be zeroed, and client will initialize
> it.
> 
> If memory does not need to be zero'd, call the new
> memblock_virt_alloc_raw() interface, and thus improve the boot performance.
> 
> Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
> Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
> Reviewed-by: Bob Picco <bob.picco@oracle.com>

OK, but as mentioned in the previous patch add memblock_virt_alloc_raw
in this patch.

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  mm/page_alloc.c | 15 +++++++--------
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 4d32c1fa4c6c..000806298dfb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7354,18 +7354,17 @@ void *__init alloc_large_system_hash(const char *tablename,
>  
>  	log2qty = ilog2(numentries);
>  
> -	/*
> -	 * memblock allocator returns zeroed memory already, so HASH_ZERO is
> -	 * currently not used when HASH_EARLY is specified.
> -	 */
>  	gfp_flags = (flags & HASH_ZERO) ? GFP_ATOMIC | __GFP_ZERO : GFP_ATOMIC;
>  	do {
>  		size = bucketsize << log2qty;
> -		if (flags & HASH_EARLY)
> -			table = memblock_virt_alloc_nopanic(size, 0);
> -		else if (hashdist)
> +		if (flags & HASH_EARLY) {
> +			if (flags & HASH_ZERO)
> +				table = memblock_virt_alloc_nopanic(size, 0);
> +			else
> +				table = memblock_virt_alloc_raw(size, 0);
> +		} else if (hashdist) {
>  			table = __vmalloc(size, gfp_flags, PAGE_KERNEL);
> -		else {
> +		} else {
>  			/*
>  			 * If bucketsize is not a power-of-two, we may free
>  			 * some pages at the end of hash table which
> -- 
> 2.14.0

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]


#1709800

FromPasha Tatashin <pasha.tatashin@oracle.com>
Date2017-08-11 18:20 +0200
Message-ID<udkPg-5Kw-7@gated-at.bofh.it>
In reply to#1709587
>> Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify
>> that memory that was allocated for system hash needs to be zeroed,
>> otherwise the memory does not need to be zeroed, and client will initialize
>> it.
>>
>> If memory does not need to be zero'd, call the new
>> memblock_virt_alloc_raw() interface, and thus improve the boot performance.
>>
>> Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
>> Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
>> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
>> Reviewed-by: Bob Picco <bob.picco@oracle.com>
> 
> OK, but as mentioned in the previous patch add memblock_virt_alloc_raw
> in this patch.
> 
> Acked-by: Michal Hocko <mhocko@suse.com>

Ok I will merge them.

Thank you,
Pasha

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web