Message ID | 20201128152559.999540-12-npiggin@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | huge vmalloc mappings | expand |
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on arm64/for-next/core linus/master v5.10-rc5]
[cannot apply to hnaz-linux-mm/master next-20201127]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/huge-vmalloc-mappings/20201128-232946
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: microblaze-randconfig-r035-20201128 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/95e5da88c21d305af971ed4f00112f0576c2b94f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nicholas-Piggin/huge-vmalloc-mappings/20201128-232946
git checkout 95e5da88c21d305af971ed4f00112f0576c2b94f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=microblaze
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
microblaze-linux-ld: mm/page_alloc.o: in function `alloc_large_system_hash':
>> (.init.text+0x4144): undefined reference to `find_vm_area'
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on arm64/for-next/core linus/master v5.10-rc5]
[cannot apply to hnaz-linux-mm/master next-20201127]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/huge-vmalloc-mappings/20201128-232946
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: h8300-randconfig-r032-20201128 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/95e5da88c21d305af971ed4f00112f0576c2b94f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nicholas-Piggin/huge-vmalloc-mappings/20201128-232946
git checkout 95e5da88c21d305af971ed4f00112f0576c2b94f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
h8300-linux-ld: arch/h8300/kernel/entry.o: in function `resume_kernel':
(.text+0x29e): undefined reference to `TI_PRE_COUNT'
h8300-linux-ld: mm/page_alloc.o: in function `.L1614':
>> page_alloc.c:(.init.text+0x2187): undefined reference to `find_vm_area'
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote: > Support huge page vmalloc mappings. Config option > HAVE_ARCH_HUGE_VMALLOC > enables support on architectures that define HAVE_ARCH_HUGE_VMAP and > supports PMD sized vmap mappings. > > vmalloc will attempt to allocate PMD-sized pages if allocating PMD > size > or larger, and fall back to small pages if that was unsuccessful. > > Allocations that do not use PAGE_KERNEL prot are not permitted to use > huge pages, because not all callers expect this (e.g., module > allocations vs strict module rwx). Several architectures (x86, arm64, others?) allocate modules initially with PAGE_KERNEL and so I think this test will not exclude module allocations in those cases. [snip] > @@ -2400,6 +2453,7 @@ static inline void set_area_direct_map(const > struct vm_struct *area, > { > int i; > > + /* HUGE_VMALLOC passes small pages to set_direct_map */ > for (i = 0; i < area->nr_pages; i++) > if (page_address(area->pages[i])) > set_direct_map(area->pages[i]); > @@ -2433,11 +2487,12 @@ static void vm_remove_mappings(struct > vm_struct *area, int deallocate_pages) > * map. Find the start and end range of the direct mappings to > make sure > * the vm_unmap_aliases() flush includes the direct map. > */ > - for (i = 0; i < area->nr_pages; i++) { > + for (i = 0; i < area->nr_pages; i += 1U << area->page_order) { > unsigned long addr = (unsigned long)page_address(area- > >pages[i]); > if (addr) { > + unsigned long page_size = PAGE_SIZE << area- > >page_order; > start = min(addr, start); > - end = max(addr + PAGE_SIZE, end); > + end = max(addr + page_size, end); > flush_dmap = 1; > } > } The logic around this is a bit tangled. The reset of the direct map has to succeed, but if the set_direct_map_() functions require a split they could fail. For x86, set_memory_ro() calls on a vmalloc alias will mirror the page size and permission on the direct map and so the direct map will be broken to 4k pages if it's a RO vmalloc allocation. But after this, module vmalloc()'s could have large pages which would result in large RO pages on the direct map. Then it could possibly fail when trying to reset a 4k page out of a large RO direct map mapping. I think either module allocations need to be actually excluded from having large pages (seems like you might have seen other issues as well?), or another option could be to use the changes here: https://lore.kernel.org/lkml/20201125092208.12544-4-rppt@kernel.org/ to reset the direct map for a large page range at a time for large vmalloc pages.
On Mon, 2020-11-30 at 12:21 -0800, Rick Edgecombe wrote: > another option could be to use the changes here: > https://lore.kernel.org/lkml/20201125092208.12544-4-rppt@kernel.org/ > to reset the direct map for a large page range at a time for large > vmalloc pages. Oops, sorry. This wouldn't be so simple because hibernate currently expects NP direct map pages to be 4k.
Excerpts from Edgecombe, Rick P's message of December 1, 2020 6:21 am: > On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote: >> Support huge page vmalloc mappings. Config option >> HAVE_ARCH_HUGE_VMALLOC >> enables support on architectures that define HAVE_ARCH_HUGE_VMAP and >> supports PMD sized vmap mappings. >> >> vmalloc will attempt to allocate PMD-sized pages if allocating PMD >> size >> or larger, and fall back to small pages if that was unsuccessful. >> >> Allocations that do not use PAGE_KERNEL prot are not permitted to use >> huge pages, because not all callers expect this (e.g., module >> allocations vs strict module rwx). > > Several architectures (x86, arm64, others?) allocate modules initially > with PAGE_KERNEL and so I think this test will not exclude module > allocations in those cases. Ah, thanks. I guess archs must additionally ensure that their PAGE_KERNEL allocations are suitable for huge page mappings before enabling the option. If there is interest from those archs to support this, I have an early (un-posted) patch that adds an explicit VM_HUGE flag that could override the pessemistic arch default. It's not much trouble to add this to the large system hash allocations. It's very out of date now but I can at least give what I have to anyone doing an arch support that wants it. > > [snip] > >> @@ -2400,6 +2453,7 @@ static inline void set_area_direct_map(const >> struct vm_struct *area, >> { >> int i; >> >> + /* HUGE_VMALLOC passes small pages to set_direct_map */ >> for (i = 0; i < area->nr_pages; i++) >> if (page_address(area->pages[i])) >> set_direct_map(area->pages[i]); >> @@ -2433,11 +2487,12 @@ static void vm_remove_mappings(struct >> vm_struct *area, int deallocate_pages) >> * map. Find the start and end range of the direct mappings to >> make sure >> * the vm_unmap_aliases() flush includes the direct map. >> */ >> - for (i = 0; i < area->nr_pages; i++) { >> + for (i = 0; i < area->nr_pages; i += 1U << area->page_order) { >> unsigned long addr = (unsigned long)page_address(area- >> >pages[i]); >> if (addr) { >> + unsigned long page_size = PAGE_SIZE << area- >> >page_order; >> start = min(addr, start); >> - end = max(addr + PAGE_SIZE, end); >> + end = max(addr + page_size, end); >> flush_dmap = 1; >> } >> } > > The logic around this is a bit tangled. The reset of the direct map has > to succeed, but if the set_direct_map_() functions require a split they > could fail. For x86, set_memory_ro() calls on a vmalloc alias will > mirror the page size and permission on the direct map and so the direct > map will be broken to 4k pages if it's a RO vmalloc allocation. > > But after this, module vmalloc()'s could have large pages which would > result in large RO pages on the direct map. Then it could possibly fail > when trying to reset a 4k page out of a large RO direct map mapping. > > I think either module allocations need to be actually excluded from > having large pages (seems like you might have seen other issues as > well?), or another option could be to use the changes here: > https://lore.kernel.org/lkml/20201125092208.12544-4-rppt@kernel.org/ > to reset the direct map for a large page range at a time for large > vmalloc pages. > Right, x86 would have to do something about that before enabling. A VM_HUGE flag might be quick and easy but maybe other options are not too difficult. Thanks, Nick
On Fri, 2020-12-04 at 18:12 +1000, Nicholas Piggin wrote: > Excerpts from Edgecombe, Rick P's message of December 1, 2020 6:21 > am: > > On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote: > > > Support huge page vmalloc mappings. Config option > > > HAVE_ARCH_HUGE_VMALLOC > > > enables support on architectures that define HAVE_ARCH_HUGE_VMAP > > > and > > > supports PMD sized vmap mappings. > > > > > > vmalloc will attempt to allocate PMD-sized pages if allocating > > > PMD > > > size > > > or larger, and fall back to small pages if that was unsuccessful. > > > > > > Allocations that do not use PAGE_KERNEL prot are not permitted to > > > use > > > huge pages, because not all callers expect this (e.g., module > > > allocations vs strict module rwx). > > > > Several architectures (x86, arm64, others?) allocate modules > > initially > > with PAGE_KERNEL and so I think this test will not exclude module > > allocations in those cases. > > Ah, thanks. I guess archs must additionally ensure that their > PAGE_KERNEL allocations are suitable for huge page mappings before > enabling the option. > > If there is interest from those archs to support this, I have an > early (un-posted) patch that adds an explicit VM_HUGE flag that could > override the pessemistic arch default. It's not much trouble to add > this > to the large system hash allocations. It's very out of date now but > I > can at least give what I have to anyone doing an arch support that > wants it. Ahh, sorry, I totally missed that this was only enabled for powerpc. That patch might be useful for me actually. Or maybe a VM_NOHUGE, since there are only a few places where executable vmallocs are created? I'm not sure what the other issues are. I am endeavoring to have small module allocations share large pages, so this infrastructure is a big help already. https://lore.kernel.org/lkml/20201120202426.18009-1-rick.p.edgecombe@intel.com/ Thanks!
Excerpts from Edgecombe, Rick P's message of December 5, 2020 4:33 am: > On Fri, 2020-12-04 at 18:12 +1000, Nicholas Piggin wrote: >> Excerpts from Edgecombe, Rick P's message of December 1, 2020 6:21 >> am: >> > On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote: >> > > Support huge page vmalloc mappings. Config option >> > > HAVE_ARCH_HUGE_VMALLOC >> > > enables support on architectures that define HAVE_ARCH_HUGE_VMAP >> > > and >> > > supports PMD sized vmap mappings. >> > > >> > > vmalloc will attempt to allocate PMD-sized pages if allocating >> > > PMD >> > > size >> > > or larger, and fall back to small pages if that was unsuccessful. >> > > >> > > Allocations that do not use PAGE_KERNEL prot are not permitted to >> > > use >> > > huge pages, because not all callers expect this (e.g., module >> > > allocations vs strict module rwx). >> > >> > Several architectures (x86, arm64, others?) allocate modules >> > initially >> > with PAGE_KERNEL and so I think this test will not exclude module >> > allocations in those cases. >> >> Ah, thanks. I guess archs must additionally ensure that their >> PAGE_KERNEL allocations are suitable for huge page mappings before >> enabling the option. >> >> If there is interest from those archs to support this, I have an >> early (un-posted) patch that adds an explicit VM_HUGE flag that could >> override the pessemistic arch default. It's not much trouble to add >> this >> to the large system hash allocations. It's very out of date now but >> I >> can at least give what I have to anyone doing an arch support that >> wants it. > > Ahh, sorry, I totally missed that this was only enabled for powerpc. > > That patch might be useful for me actually. Or maybe a VM_NOHUGE, since > there are only a few places where executable vmallocs are created? I'm > not sure what the other issues are. Yeah good question, VM_HUGE might be safer but maybe it would be possible there's only a few problems that have to be annotated with VM_NOHUGE, good point. I'll dig it out and see. > I am endeavoring to have small module allocations share large pages, so > this infrastructure is a big help already. > https://lore.kernel.org/lkml/20201120202426.18009-1-rick.p.edgecombe@intel.com/ Oh nice that's what I wanted to do next! We should try get this work for x86 as well then. Thanks, Nick
diff --git a/arch/Kconfig b/arch/Kconfig index 56b6ccc0e32d..94f5093fa6f5 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -662,6 +662,10 @@ config HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD config HAVE_ARCH_HUGE_VMAP bool +config HAVE_ARCH_HUGE_VMALLOC + depends on HAVE_ARCH_HUGE_VMAP + bool + config ARCH_WANT_HUGE_PMD_SHARE bool diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index a5ae791dc1e0..72b106c2b4da 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -59,6 +59,7 @@ struct vm_struct { unsigned long size; unsigned long flags; struct page **pages; + unsigned int page_order; unsigned int nr_pages; phys_addr_t phys_addr; const void *caller; diff --git a/mm/page_alloc.c b/mm/page_alloc.c index eaa227a479e4..35bdc411bd49 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -70,6 +70,7 @@ #include <linux/psi.h> #include <linux/padata.h> #include <linux/khugepaged.h> +#include <linux/vmalloc.h> #include <asm/sections.h> #include <asm/tlbflush.h> @@ -8171,6 +8172,7 @@ void *__init alloc_large_system_hash(const char *tablename, void *table = NULL; gfp_t gfp_flags; bool virt; + bool huge; /* allow the kernel cmdline to have a say */ if (!numentries) { @@ -8238,6 +8240,7 @@ void *__init alloc_large_system_hash(const char *tablename, } else if (get_order(size) >= MAX_ORDER || hashdist) { table = __vmalloc(size, gfp_flags); virt = true; + huge = (find_vm_area(table)->page_order > 0); } else { /* * If bucketsize is not a power-of-two, we may free @@ -8254,7 +8257,7 @@ void *__init alloc_large_system_hash(const char *tablename, pr_info("%s hash table entries: %ld (order: %d, %lu bytes, %s)\n", tablename, 1UL << log2qty, ilog2(size) - PAGE_SHIFT, size, - virt ? "vmalloc" : "linear"); + virt ? (huge ? "vmalloc hugepage" : "vmalloc") : "linear"); if (_hash_shift) *_hash_shift = log2qty; diff --git a/mm/vmalloc.c b/mm/vmalloc.c index ee9c3bee67f5..f650b26a0e83 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -42,6 +42,19 @@ #include "internal.h" #include "pgalloc-track.h" +#ifdef CONFIG_HAVE_ARCH_HUGE_VMALLOC +static bool __ro_after_init vmap_allow_huge = true; + +static int __init set_nohugevmalloc(char *str) +{ + vmap_allow_huge = false; + return 0; +} +early_param("nohugevmalloc", set_nohugevmalloc); +#else /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */ +static const bool vmap_allow_huge = false; +#endif /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */ + bool is_vmalloc_addr(const void *x) { unsigned long addr = (unsigned long)x; @@ -477,31 +490,12 @@ static int vmap_pages_p4d_range(pgd_t *pgd, unsigned long addr, return 0; } -/** - * map_kernel_range_noflush - map kernel VM area with the specified pages - * @addr: start of the VM area to map - * @size: size of the VM area to map - * @prot: page protection flags to use - * @pages: pages to map - * - * Map PFN_UP(@size) pages at @addr. The VM area @addr and @size specify should - * have been allocated using get_vm_area() and its friends. - * - * NOTE: - * This function does NOT do any cache flushing. The caller is responsible for - * calling flush_cache_vmap() on to-be-mapped areas before calling this - * function. - * - * RETURNS: - * 0 on success, -errno on failure. - */ -int map_kernel_range_noflush(unsigned long addr, unsigned long size, - pgprot_t prot, struct page **pages) +static int vmap_small_pages_range_noflush(unsigned long addr, unsigned long end, + pgprot_t prot, struct page **pages) { unsigned long start = addr; - unsigned long end = addr + size; - unsigned long next; pgd_t *pgd; + unsigned long next; int err = 0; int nr = 0; pgtbl_mod_mask mask = 0; @@ -523,6 +517,65 @@ int map_kernel_range_noflush(unsigned long addr, unsigned long size, return 0; } +static int vmap_pages_range_noflush(unsigned long addr, unsigned long end, + pgprot_t prot, struct page **pages, unsigned int page_shift) +{ + unsigned int i, nr = (end - addr) >> PAGE_SHIFT; + + WARN_ON(page_shift < PAGE_SHIFT); + + if (page_shift == PAGE_SHIFT) + return vmap_small_pages_range_noflush(addr, end, prot, pages); + + for (i = 0; i < nr; i += 1U << (page_shift - PAGE_SHIFT)) { + int err; + + err = vmap_range_noflush(addr, addr + (1UL << page_shift), + __pa(page_address(pages[i])), prot, + page_shift); + if (err) + return err; + + addr += 1UL << page_shift; + } + + return 0; +} + +static int vmap_pages_range(unsigned long addr, unsigned long end, + pgprot_t prot, struct page **pages, unsigned int page_shift) +{ + int err; + + err = vmap_pages_range_noflush(addr, end, prot, pages, page_shift); + flush_cache_vmap(addr, end); + return err; +} + +/** + * map_kernel_range_noflush - map kernel VM area with the specified pages + * @addr: start of the VM area to map + * @size: size of the VM area to map + * @prot: page protection flags to use + * @pages: pages to map + * + * Map PFN_UP(@size) pages at @addr. The VM area @addr and @size specify should + * have been allocated using get_vm_area() and its friends. + * + * NOTE: + * This function does NOT do any cache flushing. The caller is responsible for + * calling flush_cache_vmap() on to-be-mapped areas before calling this + * function. + * + * RETURNS: + * 0 on success, -errno on failure. + */ +int map_kernel_range_noflush(unsigned long addr, unsigned long size, + pgprot_t prot, struct page **pages) +{ + return vmap_pages_range_noflush(addr, addr + size, prot, pages, PAGE_SHIFT); +} + int map_kernel_range(unsigned long start, unsigned long size, pgprot_t prot, struct page **pages) { @@ -2400,6 +2453,7 @@ static inline void set_area_direct_map(const struct vm_struct *area, { int i; + /* HUGE_VMALLOC passes small pages to set_direct_map */ for (i = 0; i < area->nr_pages; i++) if (page_address(area->pages[i])) set_direct_map(area->pages[i]); @@ -2433,11 +2487,12 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages) * map. Find the start and end range of the direct mappings to make sure * the vm_unmap_aliases() flush includes the direct map. */ - for (i = 0; i < area->nr_pages; i++) { + for (i = 0; i < area->nr_pages; i += 1U << area->page_order) { unsigned long addr = (unsigned long)page_address(area->pages[i]); if (addr) { + unsigned long page_size = PAGE_SIZE << area->page_order; start = min(addr, start); - end = max(addr + PAGE_SIZE, end); + end = max(addr + page_size, end); flush_dmap = 1; } } @@ -2480,11 +2535,11 @@ static void __vunmap(const void *addr, int deallocate_pages) if (deallocate_pages) { int i; - for (i = 0; i < area->nr_pages; i++) { + for (i = 0; i < area->nr_pages; i += 1U << area->page_order) { struct page *page = area->pages[i]; BUG_ON(!page); - __free_pages(page, 0); + __free_pages(page, area->page_order); } atomic_long_sub(area->nr_pages, &nr_vmalloc_pages); @@ -2674,12 +2729,17 @@ EXPORT_SYMBOL_GPL(vmap_pfn); #endif /* CONFIG_VMAP_PFN */ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, - pgprot_t prot, int node) + pgprot_t prot, unsigned int page_shift, + int node) { const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO; - unsigned int nr_pages = get_vm_area_size(area) >> PAGE_SHIFT; - unsigned int array_size = nr_pages * sizeof(struct page *), i; + unsigned int page_order = page_shift - PAGE_SHIFT; + unsigned long addr = (unsigned long)area->addr; + unsigned long size = get_vm_area_size(area); + unsigned int nr_small_pages = size >> PAGE_SHIFT; + unsigned int array_size = nr_small_pages * sizeof(struct page *); struct page **pages; + unsigned int i; gfp_mask |= __GFP_NOWARN; if (!(gfp_mask & (GFP_DMA | GFP_DMA32))) @@ -2700,30 +2760,35 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, } area->pages = pages; - area->nr_pages = nr_pages; + area->nr_pages = nr_small_pages; + area->page_order = page_order; - for (i = 0; i < area->nr_pages; i++) { + /* + * Careful, we allocate and map page_order pages, but tracking is done + * per PAGE_SIZE page so as to keep the vm_struct APIs independent of + * the physical/mapped size. + */ + for (i = 0; i < area->nr_pages; i += 1U << page_order) { struct page *page; + int p; - if (node == NUMA_NO_NODE) - page = alloc_page(gfp_mask); - else - page = alloc_pages_node(node, gfp_mask, 0); - + page = alloc_pages_node(node, gfp_mask, page_order); if (unlikely(!page)) { /* Successfully allocated i pages, free them in __vfree() */ area->nr_pages = i; atomic_long_add(area->nr_pages, &nr_vmalloc_pages); goto fail; } - area->pages[i] = page; + + for (p = 0; p < (1U << page_order); p++) + area->pages[i + p] = page + p; + if (gfpflags_allow_blocking(gfp_mask)) cond_resched(); } atomic_long_add(area->nr_pages, &nr_vmalloc_pages); - if (map_kernel_range((unsigned long)area->addr, get_vm_area_size(area), - prot, pages) < 0) + if (vmap_pages_range(addr, addr + size, prot, pages, page_shift) < 0) goto fail; return area->addr; @@ -2731,7 +2796,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, fail: warn_alloc(gfp_mask, NULL, "vmalloc: allocation failure, allocated %ld of %ld bytes", - (area->nr_pages*PAGE_SIZE), area->size); + (area->nr_pages*PAGE_SIZE), size); __vfree(area->addr); return NULL; } @@ -2762,19 +2827,43 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align, struct vm_struct *area; void *addr; unsigned long real_size = size; + unsigned long real_align = align; + unsigned int shift = PAGE_SHIFT; - size = PAGE_ALIGN(size); if (!size || (size >> PAGE_SHIFT) > totalram_pages()) goto fail; - area = __get_vm_area_node(real_size, align, VM_ALLOC | VM_UNINITIALIZED | + if (vmap_allow_huge && arch_vmap_pmd_supported(prot) && + (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))) { + unsigned long size_per_node; + + /* + * Try huge pages. Only try for PAGE_KERNEL allocations, + * others like modules don't yet expect huge pages in + * their allocations due to apply_to_page_range not + * supporting them. + */ + + size_per_node = size; + if (node == NUMA_NO_NODE) + size_per_node /= num_online_nodes(); + if (size_per_node >= PMD_SIZE) { + shift = PMD_SHIFT; + align = max(real_align, 1UL << shift); + size = ALIGN(real_size, 1UL << shift); + } + } + +again: + size = PAGE_ALIGN(size); + area = __get_vm_area_node(size, align, VM_ALLOC | VM_UNINITIALIZED | vm_flags, start, end, node, gfp_mask, caller); if (!area) goto fail; - addr = __vmalloc_area_node(area, gfp_mask, prot, node); + addr = __vmalloc_area_node(area, gfp_mask, prot, shift, node); if (!addr) - return NULL; + goto fail; /* * In this function, newly allocated vm_struct has VM_UNINITIALIZED @@ -2788,8 +2877,19 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align, return addr; fail: - warn_alloc(gfp_mask, NULL, + if (shift > PAGE_SHIFT) { + free_vm_area(area); + shift = PAGE_SHIFT; + align = real_align; + size = real_size; + goto again; + } + + if (!area) { + /* Warn for area allocation, page allocations already warn */ + warn_alloc(gfp_mask, NULL, "vmalloc: allocation failure: %lu bytes", real_size); + } return NULL; }
Support huge page vmalloc mappings. Config option HAVE_ARCH_HUGE_VMALLOC enables support on architectures that define HAVE_ARCH_HUGE_VMAP and supports PMD sized vmap mappings. vmalloc will attempt to allocate PMD-sized pages if allocating PMD size or larger, and fall back to small pages if that was unsuccessful. Allocations that do not use PAGE_KERNEL prot are not permitted to use huge pages, because not all callers expect this (e.g., module allocations vs strict module rwx). When hugepage vmalloc mappings are enabled in the next patch, this reduces TLB misses by nearly 30x on a `git diff` workload on a 2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%. This can result in more internal fragmentation and memory overhead for a given allocation, an option nohugevmalloc is added to disable at boot. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> --- arch/Kconfig | 4 + include/linux/vmalloc.h | 1 + mm/page_alloc.c | 5 +- mm/vmalloc.c | 190 ++++++++++++++++++++++++++++++---------- 4 files changed, 154 insertions(+), 46 deletions(-)