On Tue, 2022-06-07 at 10:38 +0200, Arnd Bergmann wrote:
> On Tue, Jun 7, 2022 at 7:41 AM Alexander Dahl <ada@xxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxx>
-----------------------------------------------------------------
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
