| Message ID | 20220415164413.2727220-3-song@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP | expand |
On Fri, 2022-04-15 at 09:44 -0700, Song Liu wrote: > Use vmalloc_huge() in alloc_large_system_hash() so that large system > hash > (>= PMD_SIZE) could benefit from huge pages. Note that vmalloc_huge > only > allocates huge pages for systems with HAVE_ARCH_HUGE_VMALLOC. > > Reviewed-by: Christoph Hellwig <hch@lst.de> > Signed-off-by: Song Liu <song@kernel.org> Reviewed-by: Rik van Riel <riel@surriel.com>
Hi Song, On Fri, 2022-04-15 at 09:44 -0700, Song Liu wrote: > > Use vmalloc_huge() in alloc_large_system_hash() so that large system > > hash > > (>= PMD_SIZE) could benefit from huge pages. Note that vmalloc_huge > > only > > allocates huge pages for systems with HAVE_ARCH_HUGE_VMALLOC. > > > > Reviewed-by: Christoph Hellwig <hch@lst.de> > > Signed-off-by: Song Liu <song@kernel.org> > > Reviewed-by: Rik van Riel <riel@surriel.com> Thanks for your patch, which is now commit f2edd118d02dd114 ("page_alloc: use vmalloc_huge for large system hash") upstream (and which hasn't been in linux-next before). As reported by noreply@ellerman.id.au, this is breaking e.g. m68k/m5272c3_defconfig with: page_alloc.c:(.init.text+0x13de): undefined reference to `vmalloc_huge' vmalloc_huge() is provided by mm/vmalloc.c, which is not compiled if CONFIG_MMU=n. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Mon, Apr 25, 2022 at 12:07 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > vmalloc_huge() is provided by mm/vmalloc.c, which is not > compiled if CONFIG_MMU=n. Well, that's annoying. Does this trivial patch fix it for you? I get this feeling that this could be done better with a weak alias to __vmalloc(), and that could take care of the "arch doesn't support VMAP_HUGE" case too, but the attached is the stupid and straightforward version. Linus
Hi Linus, On Mon, Apr 25, 2022 at 10:18 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Mon, Apr 25, 2022 at 12:07 AM Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > vmalloc_huge() is provided by mm/vmalloc.c, which is not > > compiled if CONFIG_MMU=n. > > Well, that's annoying. > > Does this trivial patch fix it for you? Thanks, yes it does. (at least it fixes the m5272c3_defconfig build, no hardware to test). > I get this feeling that this could be done better with a weak alias to > __vmalloc(), and that could take care of the "arch doesn't support > VMAP_HUGE" case too, but the attached is the stupid and > straightforward version. Sounds reasonable. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6e5b4488a0c5..edcba80ad5ec 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -8919,7 +8919,7 @@ void *__init alloc_large_system_hash(const char *tablename, table = memblock_alloc_raw(size, SMP_CACHE_BYTES); } else if (get_order(size) >= MAX_ORDER || hashdist) { - table = __vmalloc(size, gfp_flags); + table = vmalloc_huge(size, gfp_flags); virt = true; if (table) huge = is_vm_area_hugepages(table);