Re: Finding kernel RAM consumers ?

[Joakim Tjernlund <Joakim.Tjernlund@infinera.com>]

On Tue, 2022-06-07 at 10:38 +0200, Arnd Bergmann wrote:
> On Tue, Jun 7, 2022 at 7:41 AM Alexander Dahl <ada@thorsis.com> wrote:
> > Am Fri, Jun 03, 2022 at 08:11:31PM +0200 schrieb Arnd Bergmann:
> > > On Fri, Jun 3, 2022 at 7:29 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > 
> > > I think this is a case of "patches welcome". Nobody has really needed
> > > this so far, but as even the smaller machines are slowly migrating from
> > > 32-bit to 64-bit cores, optimizing this will get interesting for more
> > >  developers. There are probably other low-hanging
> > > fruit that you can address after figuring out.
> > 
> > The SiP variants of at91 SAMA5D2 (armv7) or SAM9x60 (armv5) come with
> > 64 MiB or 128 MiB, and given the latter is a new SoC announced only
> > two or three years ago, requiring at least 256 MiB would be at best
> > unfortunate.  Given those SoCs are used in industrial applications
> > with very long support times, I think 32bit ARM will stay for years,
> > even with new products.
> 
> Yes, of course, and there is nothing wrong with that. We already see
> Cortex-A7 cores down to 7nm, all running Linux, and I expect there
> will likely be another 5 to 10 years of new 32-bit chips, and then another
> 10 years of people putting the existing chips into production, and after
> that a slow decline of users updating their kernels before supporting
> 32-bit hardware becomes too expensive to support in the kernel.

My aarch64 system with 36MB RAM just dropped from:
  Memory: 22444K/36864K available (3584K kernel code, 698K rwdata, 936K rodata, 320K init, 255K bss, 14420K reserved, 0K cma)
to 
  Memory: 29732K/36864K available (3648K kernel code, 698K rwdata, 936K rodata, 320K init, 255K bss, 7132K reserved, 0K cma)
with a small hack by Ard Biesheuvel <ardb@kernel.org>
-----------------------------------------------------------------
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)
 {

So there is hope for systems with little RAM

 Jocke