diff mbox series

[v3,09/60] arm64: mm: Reclaim unused vmemmap region for vmalloc use

Message ID 20230307140522.2311461-10-ardb@kernel.org
State New
Headers
Series arm64: Add support for LPA2 at stage1 and WXN |

Commit Message

Ard Biesheuvel March 7, 2023, 2:04 p.m. UTC 
  The vmemmap array is statically sized based on the maximum supported
size of the virtual address space, but it is located inside the upper VA
region, which is statically sized based on the *minimum* supported size
of the VA space. This doesn't matter much when using 64k pages, which is
the only configuration that currently supports 52-bit virtual
addressing.

However, upcoming LPA2 support will change this picture somewhat, as in
that case, the vmemmap array will take up more than 25% of the upper VA
region when using 4k pages. Given that most of this space is never used
when running on a system that does not support 52-bit virtual
addressing, let's reclaim the unused vmemmap area in that case.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/arm64/include/asm/pgtable.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Comments

Ryan Roberts March 7, 2023, 4:42 p.m. UTC | #1 
On 07/03/2023 14:04, Ard Biesheuvel wrote:
> The vmemmap array is statically sized based on the maximum supported
> size of the virtual address space, but it is located inside the upper VA
> region, which is statically sized based on the *minimum* supported size
> of the VA space. This doesn't matter much when using 64k pages, which is
> the only configuration that currently supports 52-bit virtual
> addressing.

As I understand it, the vmemmap section only holds struct pages, and the number
of struct pages in the system is surely a function of PA size, not VA size? So
why is the region sized based on VA size?

> 
> However, upcoming LPA2 support will change this picture somewhat, as in
> that case, the vmemmap array will take up more than 25% of the upper VA
> region when using 4k pages. Given that most of this space is never used
> when running on a system that does not support 52-bit virtual
> addressing, let's reclaim the unused vmemmap area in that case.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/arm64/include/asm/pgtable.h | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 3eff06c5d0eb73c7..2259898e8c3d990a 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -18,11 +18,15 @@
>   * VMALLOC range.
>   *
>   * VMALLOC_START: beginning of the kernel vmalloc space
> - * VMALLOC_END: extends to the available space below vmemmap, PCI I/O space
> - *	and fixed mappings
> + * VMALLOC_END: extends to the available space below vmemmap
>   */
>  #define VMALLOC_START		(MODULES_END)
> +#if VA_BITS == VA_BITS_MIN
>  #define VMALLOC_END		(VMEMMAP_START - SZ_8M)
> +#else
> +#define VMEMMAP_UNUSED_NPAGES	((_PAGE_OFFSET(vabits_actual) - PAGE_OFFSET) >> PAGE_SHIFT)
> +#define VMALLOC_END		(VMEMMAP_START + VMEMMAP_UNUSED_NPAGES * sizeof(struct page) - SZ_8M)
> +#endif
>  
>  #define vmemmap			((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
>
Ard Biesheuvel March 7, 2023, 4:58 p.m. UTC | #2 
On Tue, 7 Mar 2023 at 17:42, Ryan Roberts <ryan.roberts@arm.com> wrote:
>
> On 07/03/2023 14:04, Ard Biesheuvel wrote:
> > The vmemmap array is statically sized based on the maximum supported
> > size of the virtual address space, but it is located inside the upper VA
> > region, which is statically sized based on the *minimum* supported size
> > of the VA space. This doesn't matter much when using 64k pages, which is
> > the only configuration that currently supports 52-bit virtual
> > addressing.
>
> As I understand it, the vmemmap section only holds struct pages, and the number
> of struct pages in the system is surely a function of PA size, not VA size? So
> why is the region sized based on VA size?
>

We do not implement CONFIG_HIGHMEM on arm64, and so the addressable PA
range is bounded by the size of the linear map (and in some cases,
DRAM starts outside of the VA addressable range entirely, e.g., on AMD
Seattle with 38-bit VAs). Also, the start of the linear map (i.e.,
PAGE_OFFSET) does not correspond with PA 0x0, it is based on the
physical placement of system memory, and it is randomized in some
cases as well. This is why we have

#define vmemmap  ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))

This means btw that we could reclaim even more vmemmap space, i.e.,
nothing below phys_to_page(memblock_start_of_DRAM()) will ever be
used, but there are some intricacies with section rounding etc which
make this a bit tricky.

The main reason for this patch is to free up 15/16 of the vmemmap
region when using LPA2 and 4k pages, so that the resulting VA space
layout is identical to 48-bits/4k pages, making LPA2 support enabled a
reasonable default.



> >
> > However, upcoming LPA2 support will change this picture somewhat, as in
> > that case, the vmemmap array will take up more than 25% of the upper VA
> > region when using 4k pages. Given that most of this space is never used
> > when running on a system that does not support 52-bit virtual
> > addressing, let's reclaim the unused vmemmap area in that case.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  arch/arm64/include/asm/pgtable.h | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> > index 3eff06c5d0eb73c7..2259898e8c3d990a 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -18,11 +18,15 @@
> >   * VMALLOC range.
> >   *
> >   * VMALLOC_START: beginning of the kernel vmalloc space
> > - * VMALLOC_END: extends to the available space below vmemmap, PCI I/O space
> > - *   and fixed mappings
> > + * VMALLOC_END: extends to the available space below vmemmap
> >   */
> >  #define VMALLOC_START                (MODULES_END)
> > +#if VA_BITS == VA_BITS_MIN
> >  #define VMALLOC_END          (VMEMMAP_START - SZ_8M)
> > +#else
> > +#define VMEMMAP_UNUSED_NPAGES        ((_PAGE_OFFSET(vabits_actual) - PAGE_OFFSET) >> PAGE_SHIFT)
> > +#define VMALLOC_END          (VMEMMAP_START + VMEMMAP_UNUSED_NPAGES * sizeof(struct page) - SZ_8M)
> > +#endif
> >
> >  #define vmemmap                      ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
> >
>
diff mbox series

Patch

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 3eff06c5d0eb73c7..2259898e8c3d990a 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -18,11 +18,15 @@ 
  * VMALLOC range.
  *
  * VMALLOC_START: beginning of the kernel vmalloc space
- * VMALLOC_END: extends to the available space below vmemmap, PCI I/O space
- *	and fixed mappings
+ * VMALLOC_END: extends to the available space below vmemmap
  */
 #define VMALLOC_START		(MODULES_END)
+#if VA_BITS == VA_BITS_MIN
 #define VMALLOC_END		(VMEMMAP_START - SZ_8M)
+#else
+#define VMEMMAP_UNUSED_NPAGES	((_PAGE_OFFSET(vabits_actual) - PAGE_OFFSET) >> PAGE_SHIFT)
+#define VMALLOC_END		(VMEMMAP_START + VMEMMAP_UNUSED_NPAGES * sizeof(struct page) - SZ_8M)
+#endif
 
 #define vmemmap			((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))