SPARSEMEM memory needs?
Ard Biesheuvel
ardb at kernel.org
Tue Jun 7 00:48:29 PDT 2022
On Tue, 7 Jun 2022 at 09:39, Joakim Tjernlund
<Joakim.Tjernlund at infinera.com> wrote:
>
> On Tue, 2022-06-07 at 09:15 +0200, Ard Biesheuvel wrote:
..
> >
> > What you might try is changing the section size to 32 MB and mapping
> > the vmemmap region down to pages. That way, the vmemmap region should
> > only take up
> > - 512 KiB for the struct page array[] itself
> > - 4 KiB for the page table that replaces the 2 MB block mapping
> >
> > You could try the below and see if it makes any difference?
> >
> > diff --git a/arch/arm64/include/asm/sparsemem.h
> > b/arch/arm64/include/asm/sparsemem.h
> > index 4b73463423c3..a008f4342532 100644
> > --- a/arch/arm64/include/asm/sparsemem.h
> > +++ b/arch/arm64/include/asm/sparsemem.h
> > @@ -23,7 +23,7 @@
> > * entries could not be created for vmemmap mappings.
> > * 16K follows 4K for simplicity.
> > */
> > -#define SECTION_SIZE_BITS 27
> > +#define SECTION_SIZE_BITS 25
> > #endif /* CONFIG_ARM64_64K_PAGES */
> >
> > #endif
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 5b1946f1805c..d25560a53a67 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1196,7 +1196,7 @@ static void free_empty_tables(unsigned long
> > addr, unsigned long end,
> > }
> > #endif
> >
> > -#if !ARM64_KERNEL_USES_PMD_MAPS
> > +#if 1// !ARM64_KERNEL_USES_PMD_MAPS
> > int __meminit vmemmap_populate(unsigned long start, unsigned long
> > end, int node,
> > struct vmem_altmap *altmap)
> > {
>
> That was a really good idea, now I have:
> Memory: 29732K/36864K available (3648K kernel code, 698K rwdata, 936K rodata, 320K init, 255K bss, 7132K reserved, 0K cma-reserved)
>
> Reserved dropped from 14+MB to 7+MB :)
>
Glad to hear that.
> Should I look into something particular before testing this in a bigger scale?
>
A bit of stress testing would be useful, although I wouldn't be able
to recommend anything that will be able to run with that little
memory.
Just be aware that this is not a change that is likely to be accepted
by the arm64 maintainers - it is something you will have to carry in
your downstream.
Out of curiosity, what type of system is this? What user space are you using?
More information about the linux-arm-kernel
mailing list