From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicholas Piggin Subject: [PATCH v2 0/4] huge vmalloc mappings Date: Mon, 13 Apr 2020 22:52:59 +1000 Message-ID: <20200413125303.423864-1-npiggin@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane-mx.org@lists.infradead.org To: linux-mm@kvack.org Cc: linux-arch@vger.kernel.org, Catalin Marinas , x86@kernel.org, linuxppc-dev@lists.ozlabs.org, Nicholas Piggin , linux-kernel@vger.kernel.org, Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Thomas Gleixner , Will Deacon , linux-arm-kernel@lists.infradead.org List-Id: linux-arch.vger.kernel.org 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. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Nicholas Piggin Subject: [PATCH v2 0/4] huge vmalloc mappings Date: Mon, 13 Apr 2020 22:52:59 +1000 Message-ID: <20200413125303.423864-1-npiggin@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org To: linux-mm@kvack.org Cc: Nicholas Piggin , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" List-ID: Message-ID: <20200413125259.XQKjC4w-_vtk1oBMIvppMUiIY1VWG0OdJLRiLKoLVN8@z> 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. 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(-) --=20 2.23.0