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

[Ard Biesheuvel]

On Tue, 7 Mar 2023 at 17:42, Ryan Roberts <ryan.roberts at 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 at 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))
> >
>