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


Groups > linux.kernel > #1692304 > unrolled thread

[PATCH] sparc64: Register hugepages during arch init

Started byNitin Gupta <nitin.m.gupta@oracle.com>
First post2017-07-20 02:20 +0200
Last post2017-07-20 21:40 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] sparc64: Register hugepages during arch init Nitin Gupta <nitin.m.gupta@oracle.com> - 2017-07-20 02:20 +0200
    Re: [PATCH] sparc64: Register hugepages during arch init David Miller <davem@davemloft.net> - 2017-07-20 21:40 +0200

#1692304 — [PATCH] sparc64: Register hugepages during arch init

FromNitin Gupta <nitin.m.gupta@oracle.com>
Date2017-07-20 02:20 +0200
Subject[PATCH] sparc64: Register hugepages during arch init
Message-ID<u57ma-7KQ-37@gated-at.bofh.it>
Add hstate for each supported hugepage size using
arch initcall. This change fixes some hugepage
parameter parsing inconsistencies:

case 1: no hugepage parameters

 Without hugepage parameters, only a hugepages-8192kB entry is visible
 in sysfs.  It's different from x86_64 where both 2M and 1G hugepage
 sizes are available.

case 2: default_hugepagesz=[64K|256M|2G]

 When specifying only a default_hugepagesz parameter, the default
 hugepage size isn't really changed and it stays at 8M. This is again
 different from x86_64.

Orabug: 25869946

Reviewed-by: Bob Picco <bob.picco@oracle.com>
Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>
---
 arch/sparc/mm/init_64.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 3c40ebd..fed73f1 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -325,6 +325,29 @@ static void __update_mmu_tsb_insert(struct mm_struct *mm, unsigned long tsb_inde
 }
 
 #ifdef CONFIG_HUGETLB_PAGE
+static void __init add_huge_page_size(unsigned long size)
+{
+	unsigned int order;
+
+	if (size_to_hstate(size))
+		return;
+
+	order = ilog2(size) - PAGE_SHIFT;
+	hugetlb_add_hstate(order);
+}
+
+static int __init hugetlbpage_init(void)
+{
+	add_huge_page_size(1UL << HPAGE_64K_SHIFT);
+	add_huge_page_size(1UL << HPAGE_SHIFT);
+	add_huge_page_size(1UL << HPAGE_256MB_SHIFT);
+	add_huge_page_size(1UL << HPAGE_2GB_SHIFT);
+
+	return 0;
+}
+
+arch_initcall(hugetlbpage_init);
+
 static int __init setup_hugepagesz(char *string)
 {
 	unsigned long long hugepage_size;
@@ -364,7 +387,7 @@ static int __init setup_hugepagesz(char *string)
 		goto out;
 	}
 
-	hugetlb_add_hstate(hugepage_shift - PAGE_SHIFT);
+	add_huge_page_size(hugepage_size);
 	rc = 1;
 
 out:
-- 
2.9.2

[toc] | [next] | [standalone]


#1693191

FromDavid Miller <davem@davemloft.net>
Date2017-07-20 21:40 +0200
Message-ID<u5psJ-3ei-15@gated-at.bofh.it>
In reply to#1692304
From: Nitin Gupta <nitin.m.gupta@oracle.com>
Date: Wed, 19 Jul 2017 17:12:54 -0700

> Add hstate for each supported hugepage size using
> arch initcall. This change fixes some hugepage
> parameter parsing inconsistencies:
> 
> case 1: no hugepage parameters
> 
>  Without hugepage parameters, only a hugepages-8192kB entry is visible
>  in sysfs.  It's different from x86_64 where both 2M and 1G hugepage
>  sizes are available.
> 
> case 2: default_hugepagesz=[64K|256M|2G]
> 
>  When specifying only a default_hugepagesz parameter, the default
>  hugepage size isn't really changed and it stays at 8M. This is again
>  different from x86_64.
> 
> Orabug: 25869946
> 
> Reviewed-by: Bob Picco <bob.picco@oracle.com>
> Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>

Applied and queued up for -stable, thanks.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web