On Mon, 13 Apr 2020, Nicholas Piggin wrote: > We can get a significant win with larger mappings for some of the big > global hashes. > > Since RFC, relevant architectures have added p?d_leaf accessors so no > real arch changes required, and I changed it not to allocate huge > mappings for modules and a bunch of other fixes. > Hi Nicholas, Any performance numbers to share besides the git diff in the last patch in the series? I'm wondering if anything from mmtests or lkp-tests makes sense to try? > Nicholas Piggin (4): > mm/vmalloc: fix vmalloc_to_page for huge vmap mappings > mm: Move ioremap page table mapping function to mm/ > mm: HUGE_VMAP arch query functions cleanup > mm/vmalloc: Hugepage vmalloc mappings > > arch/arm64/mm/mmu.c | 8 +- > arch/powerpc/mm/book3s64/radix_pgtable.c | 6 +- > arch/x86/mm/ioremap.c | 6 +- > include/linux/io.h | 3 - > include/linux/vmalloc.h | 15 + > lib/ioremap.c | 203 +---------- > mm/vmalloc.c | 413 +++++++++++++++++++---- > 7 files changed, 380 insertions(+), 274 deletions(-) > > -- > 2.23.0 > > >