I screwed up the first message, HTML email from gmail. So I hope this time it will be good. FYI: I replaced the various ARM MLs with linux-mips, and removed the personal addresses, because they already received the screw-up. Hello, > == Kernel features == > [...] > === Highmem === > > Most Arm machines are fine without highmem support and can > use something like CONFIG_VMSPLIT_2GB to address up to 2GB > of physical memory. Machines larger than only popped up > around the time of the Cortex-A15 in 2012 and for the most > part got replaced by 64-bit chips within a short time. > In addition, there are also a handful of Cortex-A9 and > Marvell CPU based machines that have either more than 2GB > of RAM or a very sparse memory map that requires highmem > support. > > Linus Walleij has done some work towards being able to use > up to 4GB of RAM with LPAE (Cortex-A7/A15 and later) > machines, which I think still needs to be finished before > we can remove support for highmem. > > === Sparsemem === > > There is a new discussion about removing support for > traditional sparsemem support, see > https://lwn.net/Articles/974517/. > > This also relates to machines that currently need highmem > support in order to use all of their RAM even if the > total size would fit into the lowmem area, e.g. on > Renesas R-Car SoCs. In theory it should be possible to > move the indirection layer from __page_to_pfn() to > __pfn_to_phys() and support discontiguous lowmem > that way, but I don't think anyone is working on that, > and I don't know if that addresses the concerns with > today's sparsemem implementation. It looks like the highmem feature is deemed for removal. I am investigating the loss of some available RAM on a GnuBee PC1 board. An highmem-enabled kernel can access a 64MB chunk of RAM that a no-highmem can't. The board has 512 MB. That's more than 10% on a RAM-poor NAS-oriented board, probably worth the hassle to get it back. I built & flashed a current OpenWRT snapshot, without any modifications, wich gave the following output: dmesg-owrt-6.6.45-custom-nomodifs: Linux version 6.6.45 (builder@buildhost) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 r27140-ccc06f6716) 13.3.0, GNU ld (GNU Binutils) 2.42) #0 SMP Tue Aug 13 10:22:33 2024 dmesg-owrt-6.6.45-custom-nomodifs: Early memory node ranges dmesg-owrt-6.6.45-custom-nomodifs: node 0: [mem 0x0000000000000000-0x000000001bffffff] dmesg-owrt-6.6.45-custom-nomodifs: node 0: [mem 0x0000000020000000-0x0000000023ffffff] dmesg-owrt-6.6.45-custom-nomodifs: Initmem setup node 0 [mem 0x0000000000000000-0x0000000023ffffff] dmesg-owrt-6.6.45-custom-nomodifs: On node 0, zone Normal: 16384 pages in unavailable ranges dmesg-owrt-6.6.45-custom-nomodifs: Memory: 441424K/458752K available (8180K kernel code, 636K rwdata, 1756K rodata, 1256K init, 227K bss, 17328K reserved, 0K cma-reserved) And then after adding CONFIG_HIGHMEM=y dmesg-owrt-6.6.45-custom-highmem: Linux version 6.6.45 (builder@buildhost) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 r27140-ccc06f6716) 13.3.0, GNU ld (GNU Binutils) 2.42) #0 SMP Tue Aug 13 10:22:33 2024 dmesg-owrt-6.6.45-custom-highmem: HighMem [mem 0x0000000020000000-0x0000000023ffffff] dmesg-owrt-6.6.45-custom-highmem: Early memory node ranges dmesg-owrt-6.6.45-custom-highmem: node 0: [mem 0x0000000000000000-0x000000001bffffff] dmesg-owrt-6.6.45-custom-highmem: node 0: [mem 0x0000000020000000-0x0000000023ffffff] dmesg-owrt-6.6.45-custom-highmem: Initmem setup node 0 [mem 0x0000000000000000-0x0000000023ffffff] dmesg-owrt-6.6.45-custom-highmem: On node 0, zone HighMem: 16384 pages in unavailable ranges dmesg-owrt-6.6.45-custom-highmem: Memory: 506352K/524288K available (8187K kernel code, 637K rwdata, 1756K rodata, 1248K init, 251K bss, 17936K reserved, 0K cma-reserved, 65536K highmem) The lost RAM is back usable. Is there an alternative to CONFIG_HIGHMEM to use that RAM chunk ? Thanks -- Vincent Legoll
