| Message ID | 20200821044427.736424-1-npiggin@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | huge vmalloc mappings | expand |
Le 21/08/2020 à 06:44, Nicholas Piggin a écrit : > I made this powerpc-only for the time being. It shouldn't be too hard to > add support for other archs that define HUGE_VMAP. I have booted x86 > with it enabled, just may not have audited everything. I like this series, but if I understand correctly it enables huge vmalloc mappings only for hugepages sizes matching a page directory levels, ie on a PPC32 it would work only for 4M hugepages. On the 8xx, we only have 8M and 512k hugepages. Any change that it can support these as well one day ? Christophe > > Hi Andrew, would you care to put this in your tree? > > Thanks, > Nick > > Since v4: > - Fixed an off-by-page-order bug in v4 > - Several minor cleanups. > - Added page order to /proc/vmallocinfo > - Added hugepage to alloc_large_system_hage output. > - Made an architecture config option, powerpc only for now. > > Since v3: > - Fixed an off-by-one bug in a loop > - Fix !CONFIG_HAVE_ARCH_HUGE_VMAP build fail > - Hopefully this time fix the arm64 vmap stack bug, thanks Jonathan > Cameron for debugging the cause of this (hopefully). > > Since v2: > - Rebased on vmalloc cleanups, split series into simpler pieces. > - Fixed several compile errors and warnings > - Keep the page array and accounting in small page units because > struct vm_struct is an interface (this should fix x86 vmap stack debug > assert). [Thanks Zefan] > > Nicholas Piggin (8): > mm/vmalloc: fix vmalloc_to_page for huge vmap mappings > mm: apply_to_pte_range warn and fail if a large pte is encountered > mm/vmalloc: rename vmap_*_range vmap_pages_*_range > lib/ioremap: rename ioremap_*_range to vmap_*_range > mm: HUGE_VMAP arch support cleanup > mm: Move vmap_range from lib/ioremap.c to mm/vmalloc.c > mm/vmalloc: add vmap_range_noflush variant > mm/vmalloc: Hugepage vmalloc mappings > > .../admin-guide/kernel-parameters.txt | 2 + > arch/Kconfig | 4 + > arch/arm64/mm/mmu.c | 12 +- > arch/powerpc/Kconfig | 1 + > arch/powerpc/mm/book3s64/radix_pgtable.c | 10 +- > arch/x86/mm/ioremap.c | 12 +- > include/linux/io.h | 9 - > include/linux/vmalloc.h | 13 + > init/main.c | 1 - > mm/ioremap.c | 231 +-------- > mm/memory.c | 60 ++- > mm/page_alloc.c | 4 +- > mm/vmalloc.c | 456 +++++++++++++++--- > 13 files changed, 476 insertions(+), 339 deletions(-) >
Excerpts from Christophe Leroy's message of August 21, 2020 3:47 pm: > > > Le 21/08/2020 à 06:44, Nicholas Piggin a écrit : >> I made this powerpc-only for the time being. It shouldn't be too hard to >> add support for other archs that define HUGE_VMAP. I have booted x86 >> with it enabled, just may not have audited everything. > > I like this series, but if I understand correctly it enables huge > vmalloc mappings only for hugepages sizes matching a page directory > levels, ie on a PPC32 it would work only for 4M hugepages. Yeah it really just uses the HUGE_VMAP mapping which is already there. > On the 8xx, we only have 8M and 512k hugepages. Any change that it can > support these as well one day ? The vmap_range interface can now handle that, then adding support is the main work. Either make it weak and arch can override it, or add some arch helpers to make the generic version create the huge pages if it's not too ugly. Then you get those large pages for ioremap for free. The vmalloc part to allocate and try to map a bigger page size and use it is quite trivial to change from PMD to an arch specific size. Thanks, Nick