* [PATCH v5 0/2] mm: using CMA for 1 GB hugepages allocation @ 2020-04-07 16:38 Roman Gushchin 2020-04-07 16:38 ` [PATCH v5 1/2] mm: cma: NUMA node interface Roman Gushchin 2020-04-07 16:38 ` [PATCH v5 2/2] mm: hugetlb: optionally allocate gigantic hugepages using cma Roman Gushchin 0 siblings, 2 replies; 7+ messages in thread From: Roman Gushchin @ 2020-04-07 16:38 UTC (permalink / raw) To: Andrew Morton Cc: Aslan Bakirov, Michal Hocko, linux-mm, kernel-team, linux-kernel, Rik van Riel, Mike Kravetz, Roman Gushchin The patchset adds a hugetlb_cma boot option, which allows to reserve a cma area which can be later used for 1 GB hugepages allocations. v5: 1) made the hugetlb_cma work if a cma reservation fails on some nodes v4: 1) added a patch from Aslan, which is adding a useful function to cma 2) removed the hard-coded archs list from docs 3) added a warning printing on non-supported archs 4) hugetlb_lock is temporarily dropped in update_and_free_page() Thanks! Aslan Bakirov (1): mm: cma: NUMA node interface Roman Gushchin (1): mm: hugetlb: optionally allocate gigantic hugepages using cma .../admin-guide/kernel-parameters.txt | 8 ++ arch/arm64/mm/init.c | 6 + arch/x86/kernel/setup.c | 4 + include/linux/cma.h | 13 ++- include/linux/hugetlb.h | 12 ++ include/linux/memblock.h | 3 + mm/cma.c | 16 +-- mm/hugetlb.c | 109 ++++++++++++++++++ mm/memblock.c | 2 +- 9 files changed, 163 insertions(+), 10 deletions(-) -- 2.25.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v5 1/2] mm: cma: NUMA node interface 2020-04-07 16:38 [PATCH v5 0/2] mm: using CMA for 1 GB hugepages allocation Roman Gushchin @ 2020-04-07 16:38 ` Roman Gushchin 2020-04-09 0:53 ` Andrew Morton 2020-04-07 16:38 ` [PATCH v5 2/2] mm: hugetlb: optionally allocate gigantic hugepages using cma Roman Gushchin 1 sibling, 1 reply; 7+ messages in thread From: Roman Gushchin @ 2020-04-07 16:38 UTC (permalink / raw) To: Andrew Morton Cc: Aslan Bakirov, Michal Hocko, linux-mm, kernel-team, linux-kernel, Rik van Riel, Mike Kravetz From: Aslan Bakirov <aslan@fb.com> I've noticed that there is no interfaces exposed by CMA which would let me to declare contigous memory on particular NUMA node. This patchset adds the ability to try to allocate contiguous memory on specific node. It will fallback to other nodes if the specified one doesn't work. Implement a new method for declaring contigous memory on particular node and keep cma_declare_contiguous() as a wrapper. Signed-off-by: Aslan Bakirov <aslan@fb.com> Acked-by: Michal Hocko <mhocko@kernel.org> --- include/linux/cma.h | 13 +++++++++++-- include/linux/memblock.h | 3 +++ mm/cma.c | 16 +++++++++------- mm/memblock.c | 2 +- 4 files changed, 24 insertions(+), 10 deletions(-) diff --git a/include/linux/cma.h b/include/linux/cma.h index 190184b5ff32..eae834c2162f 100644 --- a/include/linux/cma.h +++ b/include/linux/cma.h @@ -24,10 +24,19 @@ extern phys_addr_t cma_get_base(const struct cma *cma); extern unsigned long cma_get_size(const struct cma *cma); extern const char *cma_get_name(const struct cma *cma); -extern int __init cma_declare_contiguous(phys_addr_t base, +extern int __init cma_declare_contiguous_nid(phys_addr_t base, phys_addr_t size, phys_addr_t limit, phys_addr_t alignment, unsigned int order_per_bit, - bool fixed, const char *name, struct cma **res_cma); + bool fixed, const char *name, struct cma **res_cma, + int nid); +static inline int __init cma_declare_contiguous(phys_addr_t base, + phys_addr_t size, phys_addr_t limit, + phys_addr_t alignment, unsigned int order_per_bit, + bool fixed, const char *name, struct cma **res_cma) +{ + return cma_declare_contiguous_nid(base, size, limit, alignment, + order_per_bit, fixed, name, res_cma, NUMA_NO_NODE); +} extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, unsigned int order_per_bit, const char *name, diff --git a/include/linux/memblock.h b/include/linux/memblock.h index 079d17d96410..6bc37a731d27 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -348,6 +348,9 @@ static inline int memblock_get_region_node(const struct memblock_region *r) phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align, phys_addr_t start, phys_addr_t end); +phys_addr_t memblock_alloc_range_nid(phys_addr_t size, + phys_addr_t align, phys_addr_t start, + phys_addr_t end, int nid, bool exact_nid); phys_addr_t memblock_phys_alloc_try_nid(phys_addr_t size, phys_addr_t align, int nid); static inline phys_addr_t memblock_phys_alloc(phys_addr_t size, diff --git a/mm/cma.c b/mm/cma.c index be55d1988c67..0463ad2ce06b 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -220,7 +220,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, } /** - * cma_declare_contiguous() - reserve custom contiguous area + * cma_declare_contiguous_nid() - reserve custom contiguous area * @base: Base address of the reserved area optional, use 0 for any * @size: Size of the reserved area (in bytes), * @limit: End address of the reserved memory (optional, 0 for any). @@ -229,6 +229,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, * @fixed: hint about where to place the reserved area * @name: The name of the area. See function cma_init_reserved_mem() * @res_cma: Pointer to store the created cma region. + * @nid: nid of the free area to find, %NUMA_NO_NODE for any node * * This function reserves memory from early allocator. It should be * called by arch specific code once the early allocator (memblock or bootmem) @@ -238,10 +239,11 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, * If @fixed is true, reserve contiguous area at exactly @base. If false, * reserve in range from @base to @limit. */ -int __init cma_declare_contiguous(phys_addr_t base, +int __init cma_declare_contiguous_nid(phys_addr_t base, phys_addr_t size, phys_addr_t limit, phys_addr_t alignment, unsigned int order_per_bit, - bool fixed, const char *name, struct cma **res_cma) + bool fixed, const char *name, struct cma **res_cma, + int nid) { phys_addr_t memblock_end = memblock_end_of_DRAM(); phys_addr_t highmem_start; @@ -336,14 +338,14 @@ int __init cma_declare_contiguous(phys_addr_t base, * memory in case of failure. */ if (base < highmem_start && limit > highmem_start) { - addr = memblock_phys_alloc_range(size, alignment, - highmem_start, limit); + addr = memblock_alloc_range_nid(size, alignment, + highmem_start, limit, nid, false); limit = highmem_start; } if (!addr) { - addr = memblock_phys_alloc_range(size, alignment, base, - limit); + addr = memblock_alloc_range_nid(size, alignment, base, + limit, nid, false); if (!addr) { ret = -ENOMEM; goto err; diff --git a/mm/memblock.c b/mm/memblock.c index 4d06bbaded0f..c79ba6f9920c 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1349,7 +1349,7 @@ __next_mem_pfn_range_in_zone(u64 *idx, struct zone *zone, * Return: * Physical address of allocated memory block on success, %0 on failure. */ -static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, +phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, phys_addr_t align, phys_addr_t start, phys_addr_t end, int nid, bool exact_nid) -- 2.25.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v5 1/2] mm: cma: NUMA node interface 2020-04-07 16:38 ` [PATCH v5 1/2] mm: cma: NUMA node interface Roman Gushchin @ 2020-04-09 0:53 ` Andrew Morton 2020-04-09 1:15 ` Roman Gushchin 0 siblings, 1 reply; 7+ messages in thread From: Andrew Morton @ 2020-04-09 0:53 UTC (permalink / raw) To: Roman Gushchin Cc: Aslan Bakirov, Michal Hocko, linux-mm, kernel-team, linux-kernel, Rik van Riel, Mike Kravetz On Tue, 7 Apr 2020 09:38:39 -0700 Roman Gushchin <guro@fb.com> wrote: > From: Aslan Bakirov <aslan@fb.com> > > I've noticed that there is no interfaces exposed by CMA which would let me > to declare contigous memory on particular NUMA node. > > This patchset adds the ability to try to allocate contiguous memory on > specific node. It will fallback to other nodes if the specified one > doesn't work. > > Implement a new method for declaring contigous memory on particular node > and keep cma_declare_contiguous() as a wrapper. > > Signed-off-by: Aslan Bakirov <aslan@fb.com> > Acked-by: Michal Hocko <mhocko@kernel.org> This should have had your signed-off-by, as you were on the patch delivery path. Please send it along? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v5 1/2] mm: cma: NUMA node interface 2020-04-09 0:53 ` Andrew Morton @ 2020-04-09 1:15 ` Roman Gushchin 0 siblings, 0 replies; 7+ messages in thread From: Roman Gushchin @ 2020-04-09 1:15 UTC (permalink / raw) To: Andrew Morton Cc: Aslan Bakirov, Michal Hocko, linux-mm, kernel-team, linux-kernel, Rik van Riel, Mike Kravetz On Wed, Apr 08, 2020 at 05:53:12PM -0700, Andrew Morton wrote: > On Tue, 7 Apr 2020 09:38:39 -0700 Roman Gushchin <guro@fb.com> wrote: > > > From: Aslan Bakirov <aslan@fb.com> > > > > I've noticed that there is no interfaces exposed by CMA which would let me > > to declare contigous memory on particular NUMA node. > > > > This patchset adds the ability to try to allocate contiguous memory on > > specific node. It will fallback to other nodes if the specified one > > doesn't work. > > > > Implement a new method for declaring contigous memory on particular node > > and keep cma_declare_contiguous() as a wrapper. > > > > Signed-off-by: Aslan Bakirov <aslan@fb.com> > > Acked-by: Michal Hocko <mhocko@kernel.org> > > This should have had your signed-off-by, as you were on the patch > delivery path. Please send it along? > Will this work? Signed-off-by: Roman Gushchin <guro@fb.com> If not, below if the whole patch signed. Thanks! -- From 63ddb2d792b548ee480d85a42c94a9e6b4722f4f Mon Sep 17 00:00:00 2001 From: Aslan Bakirov <aslan@fb.com> Date: Mon, 6 Apr 2020 11:02:59 -0700 Subject: [PATCH 1/2] mm: cma: NUMA node interface I've noticed that there is no interfaces exposed by CMA which would let me to declare contigous memory on particular NUMA node. This patchset adds the ability to try to allocate contiguous memory on specific node. It will fallback to other nodes if the specified one doesn't work. Implement a new method for declaring contigous memory on particular node and keep cma_declare_contiguous() as a wrapper. Signed-off-by: Aslan Bakirov <aslan@fb.com> Acked-by: Michal Hocko <mhocko@kernel.org> Signed-off-by: Roman Gushchin <guro@fb.com> --- include/linux/cma.h | 13 +++++++++++-- include/linux/memblock.h | 3 +++ mm/cma.c | 16 +++++++++------- mm/memblock.c | 2 +- 4 files changed, 24 insertions(+), 10 deletions(-) diff --git a/include/linux/cma.h b/include/linux/cma.h index 190184b5ff32..eae834c2162f 100644 --- a/include/linux/cma.h +++ b/include/linux/cma.h @@ -24,10 +24,19 @@ extern phys_addr_t cma_get_base(const struct cma *cma); extern unsigned long cma_get_size(const struct cma *cma); extern const char *cma_get_name(const struct cma *cma); -extern int __init cma_declare_contiguous(phys_addr_t base, +extern int __init cma_declare_contiguous_nid(phys_addr_t base, phys_addr_t size, phys_addr_t limit, phys_addr_t alignment, unsigned int order_per_bit, - bool fixed, const char *name, struct cma **res_cma); + bool fixed, const char *name, struct cma **res_cma, + int nid); +static inline int __init cma_declare_contiguous(phys_addr_t base, + phys_addr_t size, phys_addr_t limit, + phys_addr_t alignment, unsigned int order_per_bit, + bool fixed, const char *name, struct cma **res_cma) +{ + return cma_declare_contiguous_nid(base, size, limit, alignment, + order_per_bit, fixed, name, res_cma, NUMA_NO_NODE); +} extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, unsigned int order_per_bit, const char *name, diff --git a/include/linux/memblock.h b/include/linux/memblock.h index 079d17d96410..6bc37a731d27 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -348,6 +348,9 @@ static inline int memblock_get_region_node(const struct memblock_region *r) phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align, phys_addr_t start, phys_addr_t end); +phys_addr_t memblock_alloc_range_nid(phys_addr_t size, + phys_addr_t align, phys_addr_t start, + phys_addr_t end, int nid, bool exact_nid); phys_addr_t memblock_phys_alloc_try_nid(phys_addr_t size, phys_addr_t align, int nid); static inline phys_addr_t memblock_phys_alloc(phys_addr_t size, diff --git a/mm/cma.c b/mm/cma.c index be55d1988c67..0463ad2ce06b 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -220,7 +220,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, } /** - * cma_declare_contiguous() - reserve custom contiguous area + * cma_declare_contiguous_nid() - reserve custom contiguous area * @base: Base address of the reserved area optional, use 0 for any * @size: Size of the reserved area (in bytes), * @limit: End address of the reserved memory (optional, 0 for any). @@ -229,6 +229,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, * @fixed: hint about where to place the reserved area * @name: The name of the area. See function cma_init_reserved_mem() * @res_cma: Pointer to store the created cma region. + * @nid: nid of the free area to find, %NUMA_NO_NODE for any node * * This function reserves memory from early allocator. It should be * called by arch specific code once the early allocator (memblock or bootmem) @@ -238,10 +239,11 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, * If @fixed is true, reserve contiguous area at exactly @base. If false, * reserve in range from @base to @limit. */ -int __init cma_declare_contiguous(phys_addr_t base, +int __init cma_declare_contiguous_nid(phys_addr_t base, phys_addr_t size, phys_addr_t limit, phys_addr_t alignment, unsigned int order_per_bit, - bool fixed, const char *name, struct cma **res_cma) + bool fixed, const char *name, struct cma **res_cma, + int nid) { phys_addr_t memblock_end = memblock_end_of_DRAM(); phys_addr_t highmem_start; @@ -336,14 +338,14 @@ int __init cma_declare_contiguous(phys_addr_t base, * memory in case of failure. */ if (base < highmem_start && limit > highmem_start) { - addr = memblock_phys_alloc_range(size, alignment, - highmem_start, limit); + addr = memblock_alloc_range_nid(size, alignment, + highmem_start, limit, nid, false); limit = highmem_start; } if (!addr) { - addr = memblock_phys_alloc_range(size, alignment, base, - limit); + addr = memblock_alloc_range_nid(size, alignment, base, + limit, nid, false); if (!addr) { ret = -ENOMEM; goto err; diff --git a/mm/memblock.c b/mm/memblock.c index 4d06bbaded0f..c79ba6f9920c 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1349,7 +1349,7 @@ __next_mem_pfn_range_in_zone(u64 *idx, struct zone *zone, * Return: * Physical address of allocated memory block on success, %0 on failure. */ -static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, +phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, phys_addr_t align, phys_addr_t start, phys_addr_t end, int nid, bool exact_nid) -- 2.25.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH v5 2/2] mm: hugetlb: optionally allocate gigantic hugepages using cma 2020-04-07 16:38 [PATCH v5 0/2] mm: using CMA for 1 GB hugepages allocation Roman Gushchin 2020-04-07 16:38 ` [PATCH v5 1/2] mm: cma: NUMA node interface Roman Gushchin @ 2020-04-07 16:38 ` Roman Gushchin 2020-04-07 18:15 ` Michal Hocko 1 sibling, 1 reply; 7+ messages in thread From: Roman Gushchin @ 2020-04-07 16:38 UTC (permalink / raw) To: Andrew Morton Cc: Aslan Bakirov, Michal Hocko, linux-mm, kernel-team, linux-kernel, Rik van Riel, Mike Kravetz, Roman Gushchin, Andreas Schaufler, Randy Dunlap, Joonsoo Kim 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. 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. The patch contains clean-ups and fixes proposed and implemented by Aslan Bakirov and Randy Dunlap. It also contains ideas and suggestions proposed by Rik van Riel, Michal Hocko and Mike Kravetz. Thanks! Signed-off-by: Roman Gushchin <guro@fb.com> Tested-by: Andreas Schaufler <andreas.schaufler@gmx.de> Acked-by: Mike Kravetz <mike.kravetz@oracle.com> Acked-by: Michal Hocko <mhocko@kernel.org> Cc: Aslan Bakirov <aslan@fb.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Joonsoo Kim <js1304@gmail.com> --- .../admin-guide/kernel-parameters.txt | 8 ++ arch/arm64/mm/init.c | 6 + arch/x86/kernel/setup.c | 4 + include/linux/hugetlb.h | 12 ++ mm/hugetlb.c | 109 ++++++++++++++++++ 5 files changed, 139 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 4d5a4fe22703..59cca49a5249 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1473,6 +1473,14 @@ hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET registers. Default set by CONFIG_HPET_MMAP_DEFAULT. + hugetlb_cma= [HW] The size of a cma area used for allocation + of gigantic hugepages. + Format: nn[KMGTPE] + + Reserve a cma area of given size and allocate gigantic + hugepages using the cma allocator. If enabled, the + 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 e6b545047f38..4b3fa6cd3106 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> @@ -1157,6 +1158,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 5ea05879a0a9..43a1cef8f0f1 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -895,4 +895,16 @@ 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); +extern void __init hugetlb_cma_check(void); +#else +static inline __init void hugetlb_cma_reserve(int order) +{ +} +static inline __init void hugetlb_cma_check(void) +{ +} +#endif + #endif /* _LINUX_HUGETLB_H */ diff --git a/mm/hugetlb.c b/mm/hugetlb.c index f9ea1e5197b4..22c1a56493e5 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]) + continue; + + 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); } @@ -1281,8 +1308,14 @@ static void update_and_free_page(struct hstate *h, struct page *page) set_compound_page_dtor(page, NULL_COMPOUND_DTOR); set_page_refcounted(page); if (hstate_is_gigantic(h)) { + /* + * Temporarily drop the hugetlb_lock, because + * we might block in free_gigantic_page(). + */ + spin_unlock(&hugetlb_lock); destroy_compound_gigantic_page(page, huge_page_order(h)); free_gigantic_page(page, huge_page_order(h)); + spin_lock(&hugetlb_lock); } else { __free_pages(page, huge_page_order(h)); } @@ -2538,6 +2571,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, @@ -3193,6 +3230,7 @@ static int __init hugetlb_init(void) default_hstate.max_huge_pages = default_hstate_max_huge_pages; } + hugetlb_cma_check(); hugetlb_init_hstates(); gather_bootmem_prealloc(); report_hugepages(); @@ -5505,3 +5543,74 @@ 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 bool cma_reserve_called __initdata; + +static int __init cmdline_parse_hugetlb_cma(char *p) +{ + 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; + + cma_reserve_called = true; + + 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) { + int res; + + size = min(per_node, hugetlb_cma_size - reserved); + size = round_up(size, PAGE_SIZE << order); + + res = cma_declare_contiguous_nid(0, size, 0, PAGE_SIZE << order, + 0, false, "hugetlb", + &hugetlb_cma[nid], nid); + if (res) { + pr_warn("hugetlb_cma: reservation failed: err %d, node %d", + res, nid); + continue; + } + + reserved += size; + pr_info("hugetlb_cma: reserved %lu MiB on node %d\n", + size / SZ_1M, nid); + + if (reserved >= hugetlb_cma_size) + break; + } +} + +void __init hugetlb_cma_check(void) +{ + if (!hugetlb_cma_size || cma_reserve_called) + return; + + pr_warn("hugetlb_cma: the option isn't supported by current arch\n"); +} + +#endif /* CONFIG_CMA */ -- 2.25.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v5 2/2] mm: hugetlb: optionally allocate gigantic hugepages using cma 2020-04-07 16:38 ` [PATCH v5 2/2] mm: hugetlb: optionally allocate gigantic hugepages using cma Roman Gushchin @ 2020-04-07 18:15 ` Michal Hocko 2020-04-07 18:42 ` Roman Gushchin 0 siblings, 1 reply; 7+ messages in thread From: Michal Hocko @ 2020-04-07 18:15 UTC (permalink / raw) To: Roman Gushchin Cc: Andrew Morton, Aslan Bakirov, linux-mm, kernel-team, linux-kernel, Rik van Riel, Mike Kravetz, Andreas Schaufler, Randy Dunlap, Joonsoo Kim On Tue 07-04-20 09:38:40, Roman Gushchin wrote: > 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. > > 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. > > The patch contains clean-ups and fixes proposed and implemented by > Aslan Bakirov and Randy Dunlap. It also contains ideas and suggestions > proposed by Rik van Riel, Michal Hocko and Mike Kravetz. Thanks! > > Signed-off-by: Roman Gushchin <guro@fb.com> > Tested-by: Andreas Schaufler <andreas.schaufler@gmx.de> > Acked-by: Mike Kravetz <mike.kravetz@oracle.com> > Acked-by: Michal Hocko <mhocko@kernel.org> > Cc: Aslan Bakirov <aslan@fb.com> > Cc: Randy Dunlap <rdunlap@infradead.org> > Cc: Rik van Riel <riel@surriel.com> > Cc: Joonsoo Kim <js1304@gmail.com> Thanks a lot for addressing my review feedback! -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v5 2/2] mm: hugetlb: optionally allocate gigantic hugepages using cma 2020-04-07 18:15 ` Michal Hocko @ 2020-04-07 18:42 ` Roman Gushchin 0 siblings, 0 replies; 7+ messages in thread From: Roman Gushchin @ 2020-04-07 18:42 UTC (permalink / raw) To: Michal Hocko, Andrew Morton Cc: Aslan Bakirov, linux-mm, kernel-team, linux-kernel, Rik van Riel, Mike Kravetz, Andreas Schaufler, Randy Dunlap, Joonsoo Kim On Tue, Apr 07, 2020 at 08:15:46PM +0200, Michal Hocko wrote: > On Tue 07-04-20 09:38:40, Roman Gushchin wrote: > > 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. > > > > 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. > > > > The patch contains clean-ups and fixes proposed and implemented by > > Aslan Bakirov and Randy Dunlap. It also contains ideas and suggestions > > proposed by Rik van Riel, Michal Hocko and Mike Kravetz. Thanks! > > > > Signed-off-by: Roman Gushchin <guro@fb.com> > > Tested-by: Andreas Schaufler <andreas.schaufler@gmx.de> > > Acked-by: Mike Kravetz <mike.kravetz@oracle.com> > > Acked-by: Michal Hocko <mhocko@kernel.org> > > Cc: Aslan Bakirov <aslan@fb.com> > > Cc: Randy Dunlap <rdunlap@infradead.org> > > Cc: Rik van Riel <riel@surriel.com> > > Cc: Joonsoo Kim <js1304@gmail.com> > > Thanks a lot for addressing my review feedback! Actually thank you for looking at it! Andrew, can you, please, pick this version up instead of current patches and fixes in the mm tree? It will also fix the build on the next tree. Thanks! ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-04-09 1:16 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-07 16:38 [PATCH v5 0/2] mm: using CMA for 1 GB hugepages allocation Roman Gushchin 2020-04-07 16:38 ` [PATCH v5 1/2] mm: cma: NUMA node interface Roman Gushchin 2020-04-09 0:53 ` Andrew Morton 2020-04-09 1:15 ` Roman Gushchin 2020-04-07 16:38 ` [PATCH v5 2/2] mm: hugetlb: optionally allocate gigantic hugepages using cma Roman Gushchin 2020-04-07 18:15 ` Michal Hocko 2020-04-07 18:42 ` Roman Gushchin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).