[PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma 65;5803;1c Commit 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime") has added the run-time allocation of gigantic pages. However it actually works only at early stages of the system loading, when the majority of memory is free. After some time the memory gets fragmented by non-movable pages, so the chances to find a contiguous 1 GB block are getting close to zero. Even dropping caches manually doesn't help a lot.

[PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma 65;5803;1c Commit 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime") has added the run-time allocation of gigantic pages. However it actually works only at early stages of the system loading, when the majority of memory is free. After some time the memory gets fragmented by non-movable pages, so the chances to find a contiguous 1 GB block are getting close to zero. Even dropping caches manually doesn't help a lot.

[Roman Gushchin]

At large scale rebooting servers in order to allocate gigantic hugepages
is quite expensive and complex. At the same time keeping some constant
percentage of memory in reserved hugepages even if the workload isn't
using it is a big waste: not all workloads can benefit from using 1 GB
pages.

The following solution can solve the problem:
1) On boot time a dedicated cma area* is reserved. The size is passed
   as a kernel argument.
2) Run-time allocations of gigantic hugepages are performed using the
   cma allocator and the dedicated cma area

In this case gigantic hugepages can be allocated successfully with a
high probability, however the memory isn't completely wasted if nobody
is using 1GB hugepages: it can be used for pagecache, anon memory,
THPs, etc.

* On a multi-node machine a per-node cma area is allocated on each node.
  Following gigantic hugetlb allocation are using the first available
  numa node if the mask isn't specified by a user.

Usage:
1) configure the kernel to allocate a cma area for hugetlb allocations:
   pass hugetlb_cma=10G as a kernel argument

2) allocate hugetlb pages as usual, e.g.
   echo 10 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

If the option isn't enabled or the allocation of the cma area failed,
the current behavior of the system is preserved.

x86 and arm-64 are covered by this patch, other architectures can be
trivially added later.

v3:
  - added fallback to the existing allocation mechanism
  - added min/max checks
  - switched to MiB in debug output
  - removed percentage option
  - added arch-specific order argument to determine an alignment
  - added arm support
  - fixed the !CONFIG_HUGETLBFS build

  Thanks to Michal, Mike, Andreas and Rik for ideas and suggestions!

v2:
  -fixed !CONFIG_CMA build, suggested by Andrew Morton

Signed-off-by: Roman Gushchin <guro@fb.com>
---
 .../admin-guide/kernel-parameters.txt         |   7 ++
 arch/arm64/mm/init.c                          |   6 +
 arch/x86/kernel/setup.c                       |   4 +
 include/linux/hugetlb.h                       |   8 ++
 mm/hugetlb.c                                  | 116 ++++++++++++++++++
 5 files changed, 141 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0c9894247015..9eb0df40643d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1452,6 +1452,13 @@
 	hpet_mmap=	[X86, HPET_MMAP] Allow userspace to mmap HPET
 			registers.  Default set by CONFIG_HPET_MMAP_DEFAULT.
 
+	hugetlb_cma=	[x86-64] The size of a cma area used for allocation
+			of gigantic hugepages.
+			Format: nn[KMGTPE]
+
+			If enabled, boot-time allocation of gigantic hugepages
+			is skipped.
+
 	hugepages=	[HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
 	hugepagesz=	[HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
 			On x86-64 and powerpc, this option can be specified
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index b65dffdfb201..e42727e3568e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -29,6 +29,7 @@
 #include <linux/mm.h>
 #include <linux/kexec.h>
 #include <linux/crash_dump.h>
+#include <linux/hugetlb.h>
 
 #include <asm/boot.h>
 #include <asm/fixmap.h>
@@ -457,6 +458,11 @@ void __init arm64_memblock_init(void)
 	high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
 
 	dma_contiguous_reserve(arm64_dma32_phys_limit);
+
+#ifdef CONFIG_ARM64_4K_PAGES
+	hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
+#endif
+
 }
 
 void __init bootmem_init(void)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index a74262c71484..fc3e326a62b9 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -16,6 +16,7 @@
 #include <linux/pci.h>
 #include <linux/root_dev.h>
 #include <linux/sfi.h>
+#include <linux/hugetlb.h>
 #include <linux/tboot.h>
 #include <linux/usb/xhci-dbgp.h>
 
@@ -1158,6 +1159,9 @@ void __init setup_arch(char **cmdline_p)
 	initmem_init();
 	dma_contiguous_reserve(max_pfn_mapped << PAGE_SHIFT);
 
+	if (boot_cpu_has(X86_FEATURE_GBPAGES))
+		hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
+
 	/*
 	 * Reserve memory for crash kernel after SRAT is parsed so that it
 	 * won't consume hotpluggable memory.
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 50480d16bd33..b831e9fa1a26 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -890,4 +890,12 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h,
 	return ptl;
 }
 
+#if defined(CONFIG_HUGETLB_PAGE) && defined(CONFIG_CMA)
+extern void __init hugetlb_cma_reserve(int order);
+#else
+static inline __init void hugetlb_cma_reserve(int order)
+{
+}
+#endif
+
 #endif /* _LINUX_HUGETLB_H */
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7fb31750e670..66bfc2bdc203 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -28,6 +28,7 @@
 #include <linux/jhash.h>
 #include <linux/numa.h>
 #include <linux/llist.h>
+#include <linux/cma.h>
 
 #include <asm/page.h>
 #include <asm/pgtable.h>
@@ -44,6 +45,9 @@
 int hugetlb_max_hstate __read_mostly;
 unsigned int default_hstate_idx;
 struct hstate hstates[HUGE_MAX_HSTATE];
+
+static struct cma *hugetlb_cma[MAX_NUMNODES];
+
 /*
  * Minimum page order among possible hugepage sizes, set to a proper value
  * at boot time.
@@ -1228,6 +1232,14 @@ static void destroy_compound_gigantic_page(struct page *page,
 
 static void free_gigantic_page(struct page *page, unsigned int order)
 {
+	/*
+	 * If the page isn't allocated using the cma allocator,
+	 * cma_release() returns false.
+	 */
+	if (IS_ENABLED(CONFIG_CMA) &&
+	    cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order))
+		return;
+
 	free_contig_range(page_to_pfn(page), 1 << order);
 }
 
@@ -1237,6 +1249,21 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
 {
 	unsigned long nr_pages = 1UL << huge_page_order(h);
 
+	if (IS_ENABLED(CONFIG_CMA)) {
+		struct page *page;
+		int node;
+
+		for_each_node_mask(node, *nodemask) {
+			if (!hugetlb_cma[node])
+				break;
+
+			page = cma_alloc(hugetlb_cma[node], nr_pages,
+					 huge_page_order(h), true);
+			if (page)
+				return page;
+		}
+	}
+
 	return alloc_contig_pages(nr_pages, gfp_mask, nid, nodemask);
 }
 
@@ -2439,6 +2466,10 @@ static void __init hugetlb_hstate_alloc_pages(struct hstate *h)
 
 	for (i = 0; i < h->max_huge_pages; ++i) {
 		if (hstate_is_gigantic(h)) {
+			if (IS_ENABLED(CONFIG_CMA) && hugetlb_cma[0]) {
+				pr_warn_once("HugeTLB: hugetlb_cma is enabled, skip boot time allocation\n");
+				break;
+			}
 			if (!alloc_bootmem_huge_page(h))
 				break;
 		} else if (!alloc_pool_huge_page(h,
@@ -5372,3 +5403,88 @@ void move_hugetlb_state(struct page *oldpage, struct page *newpage, int reason)
 		spin_unlock(&hugetlb_lock);
 	}
 }
+
+#ifdef CONFIG_CMA
+static unsigned long hugetlb_cma_size __initdata;
+
+static int __init cmdline_parse_hugetlb_cma(char *p)
+{
+	unsigned long long val;
+	char *endptr;
+
+	if (!p)
+		return -EINVAL;
+
+	val = simple_strtoull(p, &endptr, 0);
+	hugetlb_cma_size = memparse(p, &p);
+	return 0;
+}
+
+early_param("hugetlb_cma", cmdline_parse_hugetlb_cma);
+
+void __init hugetlb_cma_reserve(int order)
+{
+	unsigned long size, reserved, per_node;
+	int nid;
+
+	if (!hugetlb_cma_size)
+		return;
+
+	if (hugetlb_cma_size < (PAGE_SIZE << order)) {
+		pr_warn("hugetlb_cma: cma area should be at least %lu MiB\n",
+			(PAGE_SIZE << order) / SZ_1M);
+		return;
+	}
+
+	/*
+	 * If 3 GB area is requested on a machine with 4 numa nodes,
+	 * let's allocate 1 GB on first three nodes and ignore the last one.
+	 */
+	per_node = DIV_ROUND_UP(hugetlb_cma_size, nr_online_nodes);
+	pr_info("hugetlb_cma: reserve %lu MiB, up to %lu MiB per node\n",
+		hugetlb_cma_size / SZ_1M, per_node / SZ_1M);
+
+	reserved = 0;
+	for_each_node_state(nid, N_ONLINE) {
+		unsigned long start_pfn, end_pfn;
+		unsigned long min_pfn = 0, max_pfn = 0;
+		int res, i;
+
+		for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
+			if (!min_pfn)
+				min_pfn = start_pfn;
+			max_pfn = end_pfn;
+		}
+
+		size = max(per_node, hugetlb_cma_size - reserved);
+		size = round_up(size, PAGE_SIZE << order);
+
+		if (size > ((max_pfn - min_pfn) << PAGE_SHIFT) / 2) {
+			pr_warn("hugetlb_cma: cma_area is too big, please try less than %lu MiB\n",
+				round_down(((max_pfn - min_pfn) << PAGE_SHIFT) *
+					   nr_online_nodes / 2 / SZ_1M,
+					   PAGE_SIZE << order));
+			break;
+		}
+
+		res = cma_declare_contiguous(PFN_PHYS(min_pfn), size,
+					     PFN_PHYS(max_pfn),
+					     PAGE_SIZE << order,
+					     0, false,
+					     "hugetlb", &hugetlb_cma[nid]);
+		if (res) {
+			pr_warn("hugetlb_cma: reservation failed: err %d, node %d, [%llu, %llu)",
+				res, nid, PFN_PHYS(min_pfn), PFN_PHYS(max_pfn));
+			break;
+		}
+
+		reserved += size;
+		pr_info("hugetlb_cma: reserved %lu MiB on node %d\n",
+			size / SZ_1M, nid);
+
+		if (reserved >= hugetlb_cma_size)
+			break;
+	}
+}
+
+#endif /* CONFIG_CMA */
-- 
2.24.1

Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma

[Qian Cai]

On Wed, 2020-03-11 at 15:09 -0700, Roman Gushchin wrote:
> +#ifdef CONFIG_CMA
> +static unsigned long hugetlb_cma_size __initdata;
> +
> +static int __init cmdline_parse_hugetlb_cma(char *p)
> +{
> +	unsigned long long val;
> +	char *endptr;
> +
> +	if (!p)
> +		return -EINVAL;
> +
> +	val = simple_strtoull(p, &endptr, 0);
> +	hugetlb_cma_size = memparse(p, &p);
> +	return 0;
> +}
> +

Here will generate a compilation warning,

mm/hugetlb.c: In function 'cmdline_parse_hugetlb_cma':
mm/hugetlb.c:5548:21: warning: variable 'val' set but not used [-Wunused-but-
set-variable]
  unsigned long long val;
                     ^~~
Also, the comments for simple_strtoull() in lib/vsprintf.c said,

"This function is obsolete. Please use kstrtoull instead."

Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma

[Roman Gushchin]

On Thu, Mar 12, 2020 at 09:33:20AM -0400, Qian Cai wrote:
> On Wed, 2020-03-11 at 15:09 -0700, Roman Gushchin wrote:
> > +#ifdef CONFIG_CMA
> > +static unsigned long hugetlb_cma_size __initdata;
> > +
> > +static int __init cmdline_parse_hugetlb_cma(char *p)
> > +{
> > +	unsigned long long val;
> > +	char *endptr;
> > +
> > +	if (!p)
> > +		return -EINVAL;
> > +
> > +	val = simple_strtoull(p, &endptr, 0);
> > +	hugetlb_cma_size = memparse(p, &p);
> > +	return 0;
> > +}
> > +
> 
> Here will generate a compilation warning,
> 
> mm/hugetlb.c: In function 'cmdline_parse_hugetlb_cma':
> mm/hugetlb.c:5548:21: warning: variable 'val' set but not used [-Wunused-but-
> set-variable]
>   unsigned long long val;
>                      ^~~
> Also, the comments for simple_strtoull() in lib/vsprintf.c said,
> 
> "This function is obsolete. Please use kstrtoull instead."
> 

Hello Qian!

Thank you, you're absolutely right.
The following patch should solve both problems:

--

From d45741afdb9a760e48915c2d19e750f53019e19c Mon Sep 17 00:00:00 2001
From: Roman Gushchin <guro@fb.com>
Date: Thu, 12 Mar 2020 17:40:04 -0700
Subject: [PATCH] mm: cleanup cmdline_parse_hugetlb_cma()

Remove unused code.

Signed-off-by: Roman Gushchin <guro@fb.com>
---
 mm/hugetlb.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 66bfc2bdc203..7a20cae7c77a 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5409,13 +5409,6 @@ static unsigned long hugetlb_cma_size __initdata;
 
 static int __init cmdline_parse_hugetlb_cma(char *p)
 {
-       unsigned long long val;
-       char *endptr;
-
-       if (!p)
-               return -EINVAL;
-
-       val = simple_strtoull(p, &endptr, 0);
        hugetlb_cma_size = memparse(p, &p);
        return 0;
 }
-- 
2.24.1

Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma 65;5803;1c Commit 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime") has added the run-time allocation of gigantic pages. However it actually works only at early stages of the system loading, when the majority of memory is free. After some time the memory gets fragmented by non-movable pages, so the chances to find a contiguous 1 GB block are getting close to zero. Even dropping caches manually doesn't help a lot.

[Andrew Morton]

On Wed, 11 Mar 2020 15:09:20 -0700 Roman Gushchin <guro@fb.com> wrote:

> At large scale rebooting servers in order to allocate gigantic hugepages
> is quite expensive and complex. At the same time keeping some constant
> percentage of memory in reserved hugepages even if the workload isn't
> using it is a big waste: not all workloads can benefit from using 1 GB
> pages.
> 
> The following solution can solve the problem:
> 1) On boot time a dedicated cma area* is reserved. The size is passed
>    as a kernel argument.
> 2) Run-time allocations of gigantic hugepages are performed using the
>    cma allocator and the dedicated cma area
> 
> In this case gigantic hugepages can be allocated successfully with a
> high probability, however the memory isn't completely wasted if nobody
> is using 1GB hugepages: it can be used for pagecache, anon memory,
> THPs, etc.
> 
> * On a multi-node machine a per-node cma area is allocated on each node.
>   Following gigantic hugetlb allocation are using the first available
>   numa node if the mask isn't specified by a user.
> 
> Usage:
> 1) configure the kernel to allocate a cma area for hugetlb allocations:
>    pass hugetlb_cma=10G as a kernel argument
> 
> 2) allocate hugetlb pages as usual, e.g.
>    echo 10 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
> 
> If the option isn't enabled or the allocation of the cma area failed,
> the current behavior of the system is preserved.
> 
> x86 and arm-64 are covered by this patch, other architectures can be
> trivially added later.

Lots of review input on v2, but then everyone went quiet ;)

Has everything been addressed?

Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma 65;5803;1c Commit 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime") has added the run-time allocation of gigantic pages. However it actually works only at early stages of the system loading, when the majority of memory is free. After some time the memory gets fragmented by non-movable pages, so the chances to find a contiguous 1 GB block are getting close to zero. Even dropping caches manually doesn't help a lot.

[Roman Gushchin]

On Wed, Apr 01, 2020 at 07:25:53PM -0700, Andrew Morton wrote:
> On Wed, 11 Mar 2020 15:09:20 -0700 Roman Gushchin <guro@fb.com> wrote:
> 
> > At large scale rebooting servers in order to allocate gigantic hugepages
> > is quite expensive and complex. At the same time keeping some constant
> > percentage of memory in reserved hugepages even if the workload isn't
> > using it is a big waste: not all workloads can benefit from using 1 GB
> > pages.
> > 
> > The following solution can solve the problem:
> > 1) On boot time a dedicated cma area* is reserved. The size is passed
> >    as a kernel argument.
> > 2) Run-time allocations of gigantic hugepages are performed using the
> >    cma allocator and the dedicated cma area
> > 
> > In this case gigantic hugepages can be allocated successfully with a
> > high probability, however the memory isn't completely wasted if nobody
> > is using 1GB hugepages: it can be used for pagecache, anon memory,
> > THPs, etc.
> > 
> > * On a multi-node machine a per-node cma area is allocated on each node.
> >   Following gigantic hugetlb allocation are using the first available
> >   numa node if the mask isn't specified by a user.
> > 
> > Usage:
> > 1) configure the kernel to allocate a cma area for hugetlb allocations:
> >    pass hugetlb_cma=10G as a kernel argument
> > 
> > 2) allocate hugetlb pages as usual, e.g.
> >    echo 10 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
> > 
> > If the option isn't enabled or the allocation of the cma area failed,
> > the current behavior of the system is preserved.
> > 
> > x86 and arm-64 are covered by this patch, other architectures can be
> > trivially added later.
> 
> Lots of review input on v2, but then everyone went quiet ;)
> 
> Has everything been addressed?

I hope so. There is a nice cleanup from Aslan, which can be merged in or
treated as a separate patch.

If someone else has any concerns, I'm happy to address them too.

Thanks!

Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma

[Michal Hocko]

On Wed 01-04-20 19:44:06, Roman Gushchin wrote:
> On Wed, Apr 01, 2020 at 07:25:53PM -0700, Andrew Morton wrote:
> > On Wed, 11 Mar 2020 15:09:20 -0700 Roman Gushchin <guro@fb.com> wrote:
> > 
> > > At large scale rebooting servers in order to allocate gigantic hugepages
> > > is quite expensive and complex. At the same time keeping some constant
> > > percentage of memory in reserved hugepages even if the workload isn't
> > > using it is a big waste: not all workloads can benefit from using 1 GB
> > > pages.
> > > 
> > > The following solution can solve the problem:
> > > 1) On boot time a dedicated cma area* is reserved. The size is passed
> > >    as a kernel argument.
> > > 2) Run-time allocations of gigantic hugepages are performed using the
> > >    cma allocator and the dedicated cma area
> > > 
> > > In this case gigantic hugepages can be allocated successfully with a
> > > high probability, however the memory isn't completely wasted if nobody
> > > is using 1GB hugepages: it can be used for pagecache, anon memory,
> > > THPs, etc.
> > > 
> > > * On a multi-node machine a per-node cma area is allocated on each node.
> > >   Following gigantic hugetlb allocation are using the first available
> > >   numa node if the mask isn't specified by a user.
> > > 
> > > Usage:
> > > 1) configure the kernel to allocate a cma area for hugetlb allocations:
> > >    pass hugetlb_cma=10G as a kernel argument
> > > 
> > > 2) allocate hugetlb pages as usual, e.g.
> > >    echo 10 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
> > > 
> > > If the option isn't enabled or the allocation of the cma area failed,
> > > the current behavior of the system is preserved.
> > > 
> > > x86 and arm-64 are covered by this patch, other architectures can be
> > > trivially added later.
> > 
> > Lots of review input on v2, but then everyone went quiet ;)
> > 
> > Has everything been addressed?
> 
> I hope so. There is a nice cleanup from Aslan, which can be merged in or
> treated as a separate patch.

With the follow up patche I didn't have any objections. I would prefer
having hugetlb parts folded into the original patch to make the review
easier though. Then I can have a look again. If those patches are going
to be as they are now then no problem with me.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma 65;5803;1c Commit 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime") has added the run-time allocation of gigantic pages. However it actually works only at early stages of the system loading, when the majority of memory is free. After some time the memory gets fragmented by non-movable pages, so the chances to find a contiguous 1 GB block are getting close to zero. Even dropping caches manually doesn't help a lot.

[Mike Kravetz]

On 3/11/20 3:09 PM, Roman Gushchin wrote:
> At large scale rebooting servers in order to allocate gigantic hugepages
> is quite expensive and complex. At the same time keeping some constant
> percentage of memory in reserved hugepages even if the workload isn't
> using it is a big waste: not all workloads can benefit from using 1 GB
> pages.
> 
> The following solution can solve the problem:
> 1) On boot time a dedicated cma area* is reserved. The size is passed
>    as a kernel argument.
> 2) Run-time allocations of gigantic hugepages are performed using the
>    cma allocator and the dedicated cma area
> 
> In this case gigantic hugepages can be allocated successfully with a
> high probability, however the memory isn't completely wasted if nobody
> is using 1GB hugepages: it can be used for pagecache, anon memory,
> THPs, etc.
> 
> * On a multi-node machine a per-node cma area is allocated on each node.
>   Following gigantic hugetlb allocation are using the first available
>   numa node if the mask isn't specified by a user.
> 
> Usage:
> 1) configure the kernel to allocate a cma area for hugetlb allocations:
>    pass hugetlb_cma=10G as a kernel argument
> 
> 2) allocate hugetlb pages as usual, e.g.
>    echo 10 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
> 
> If the option isn't enabled or the allocation of the cma area failed,
> the current behavior of the system is preserved.
> 
> x86 and arm-64 are covered by this patch, other architectures can be
> trivially added later.
> 
> v3:
>   - added fallback to the existing allocation mechanism
>   - added min/max checks
>   - switched to MiB in debug output
>   - removed percentage option
>   - added arch-specific order argument to determine an alignment
>   - added arm support
>   - fixed the !CONFIG_HUGETLBFS build
> 
>   Thanks to Michal, Mike, Andreas and Rik for ideas and suggestions!
> 
> v2:
>   -fixed !CONFIG_CMA build, suggested by Andrew Morton
> 
> Signed-off-by: Roman Gushchin <guro@fb.com>

It is a bit difficult to keep track of all the followup patches.  One
small issue below.

> ---
>  .../admin-guide/kernel-parameters.txt         |   7 ++
>  arch/arm64/mm/init.c                          |   6 +
>  arch/x86/kernel/setup.c                       |   4 +
>  include/linux/hugetlb.h                       |   8 ++
>  mm/hugetlb.c                                  | 116 ++++++++++++++++++
>  5 files changed, 141 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 0c9894247015..9eb0df40643d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1452,6 +1452,13 @@
>  	hpet_mmap=	[X86, HPET_MMAP] Allow userspace to mmap HPET
>  			registers.  Default set by CONFIG_HPET_MMAP_DEFAULT.
>  
> +	hugetlb_cma=	[x86-64] The size of a cma area used for allocation
> +			of gigantic hugepages.
> +			Format: nn[KMGTPE]
> +
> +			If enabled, boot-time allocation of gigantic hugepages
> +			is skipped.
> +
>  	hugepages=	[HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
>  	hugepagesz=	[HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
>  			On x86-64 and powerpc, this option can be specified
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index b65dffdfb201..e42727e3568e 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -29,6 +29,7 @@
>  #include <linux/mm.h>
>  #include <linux/kexec.h>
>  #include <linux/crash_dump.h>
> +#include <linux/hugetlb.h>
>  
>  #include <asm/boot.h>
>  #include <asm/fixmap.h>
> @@ -457,6 +458,11 @@ void __init arm64_memblock_init(void)
>  	high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
>  
>  	dma_contiguous_reserve(arm64_dma32_phys_limit);
> +
> +#ifdef CONFIG_ARM64_4K_PAGES
> +	hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> +#endif
> +
>  }

The documentation is already 'out of date' as you added support for arm64.
Not a huge deal as documentation rarely keeps up with code, but we should
at least be correct here.

I have a patch series in progress which cleans up existing hugetlb command
line processing.
https://lore.kernel.org/linux-mm/20200401183819.20647-1-mike.kravetz@oracle.com/

No need to make any changes here, but assuming this support goes in first
I would make the following changes as part of my series:
- Don't list architectures in Documentation.  Just say support is arch
  dependent.
- Introduce some mechanism to print an error if hugetlb_cma is specified
  on the command line, but not supported by architecture.  IIUC, no message
  is printed today.  IMO, this only becomes important if the documentation
  does not list supported architectures.
 
Not insisting that documentation be updated to include arm64.
Acked-by: Mike Kravetz <mike.kravetz@oracle.com>
-- 
Mike Kravetz

Re: [PATCH v3] mm: hugetlb: optionally allocate gigantic hugepages using cma 65;5803;1c Commit 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime") has added the run-time allocation of gigantic pages. However it actually works only at early stages of the system loading, when the majority of memory is free. After some time the memory gets fragmented by non-movable pages, so the chances to find a contiguous 1 GB block are getting close to zero. Even dropping caches manually doesn't help a lot.

[Roman Gushchin]

On Fri, Apr 03, 2020 at 08:56:57AM -0700, Mike Kravetz wrote:
> On 3/11/20 3:09 PM, Roman Gushchin wrote:
> > At large scale rebooting servers in order to allocate gigantic hugepages
> > is quite expensive and complex. At the same time keeping some constant
> > percentage of memory in reserved hugepages even if the workload isn't
> > using it is a big waste: not all workloads can benefit from using 1 GB
> > pages.
> > 
> > The following solution can solve the problem:
> > 1) On boot time a dedicated cma area* is reserved. The size is passed
> >    as a kernel argument.
> > 2) Run-time allocations of gigantic hugepages are performed using the
> >    cma allocator and the dedicated cma area
> > 
> > In this case gigantic hugepages can be allocated successfully with a
> > high probability, however the memory isn't completely wasted if nobody
> > is using 1GB hugepages: it can be used for pagecache, anon memory,
> > THPs, etc.
> > 
> > * On a multi-node machine a per-node cma area is allocated on each node.
> >   Following gigantic hugetlb allocation are using the first available
> >   numa node if the mask isn't specified by a user.
> > 
> > Usage:
> > 1) configure the kernel to allocate a cma area for hugetlb allocations:
> >    pass hugetlb_cma=10G as a kernel argument
> > 
> > 2) allocate hugetlb pages as usual, e.g.
> >    echo 10 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
> > 
> > If the option isn't enabled or the allocation of the cma area failed,
> > the current behavior of the system is preserved.
> > 
> > x86 and arm-64 are covered by this patch, other architectures can be
> > trivially added later.
> > 
> > v3:
> >   - added fallback to the existing allocation mechanism
> >   - added min/max checks
> >   - switched to MiB in debug output
> >   - removed percentage option
> >   - added arch-specific order argument to determine an alignment
> >   - added arm support
> >   - fixed the !CONFIG_HUGETLBFS build
> > 
> >   Thanks to Michal, Mike, Andreas and Rik for ideas and suggestions!
> > 
> > v2:
> >   -fixed !CONFIG_CMA build, suggested by Andrew Morton
> > 
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> 
> It is a bit difficult to keep track of all the followup patches.  One
> small issue below.

I agree. There was a dozen of cleanups and fixes from several other people,
so it's a bit messy now.
I'll merge it all together (including documentation fixes proposed by you)
and resend, as soon as I'll figure out the hugetlb/cma locking issue.

> 
> > ---
> >  .../admin-guide/kernel-parameters.txt         |   7 ++
> >  arch/arm64/mm/init.c                          |   6 +
> >  arch/x86/kernel/setup.c                       |   4 +
> >  include/linux/hugetlb.h                       |   8 ++
> >  mm/hugetlb.c                                  | 116 ++++++++++++++++++
> >  5 files changed, 141 insertions(+)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 0c9894247015..9eb0df40643d 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -1452,6 +1452,13 @@
> >  	hpet_mmap=	[X86, HPET_MMAP] Allow userspace to mmap HPET
> >  			registers.  Default set by CONFIG_HPET_MMAP_DEFAULT.
> >  
> > +	hugetlb_cma=	[x86-64] The size of a cma area used for allocation
> > +			of gigantic hugepages.
> > +			Format: nn[KMGTPE]
> > +
> > +			If enabled, boot-time allocation of gigantic hugepages
> > +			is skipped.
> > +
> >  	hugepages=	[HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
> >  	hugepagesz=	[HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
> >  			On x86-64 and powerpc, this option can be specified
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index b65dffdfb201..e42727e3568e 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -29,6 +29,7 @@
> >  #include <linux/mm.h>
> >  #include <linux/kexec.h>
> >  #include <linux/crash_dump.h>
> > +#include <linux/hugetlb.h>
> >  
> >  #include <asm/boot.h>
> >  #include <asm/fixmap.h>
> > @@ -457,6 +458,11 @@ void __init arm64_memblock_init(void)
> >  	high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> >  
> >  	dma_contiguous_reserve(arm64_dma32_phys_limit);
> > +
> > +#ifdef CONFIG_ARM64_4K_PAGES
> > +	hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> > +#endif
> > +
> >  }
> 
> The documentation is already 'out of date' as you added support for arm64.
> Not a huge deal as documentation rarely keeps up with code, but we should
> at least be correct here.
> 
> I have a patch series in progress which cleans up existing hugetlb command
> line processing.
> https://lore.kernel.org/linux-mm/20200401183819.20647-1-mike.kravetz@oracle.com/
> 
> No need to make any changes here, but assuming this support goes in first
> I would make the following changes as part of my series:
> - Don't list architectures in Documentation.  Just say support is arch
>   dependent.
> - Introduce some mechanism to print an error if hugetlb_cma is specified
>   on the command line, but not supported by architecture.  IIUC, no message
>   is printed today.  IMO, this only becomes important if the documentation
>   does not list supported architectures.
>  
> Not insisting that documentation be updated to include arm64.
> Acked-by: Mike Kravetz <mike.kravetz@oracle.com>

Thank you!

Roman