linux-kernel - Fwd: [RFC} arm architecture board/feature deprecation timeline

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAEwRq=on1DUHwjkBxNzS7UfRrpQT=k2C943ZrjK7NJDHxijZkA@mail.gmail.com>
Date: Sat, 24 Aug 2024 07:33:31 +0000
From: Vincent Legoll <vincent.legoll@...il.com>
To: Linux Kernel ML <linux-kernel@...r.kernel.org>, linux-mips@...r.kernel.org
Subject: Fwd: [RFC} arm architecture board/feature deprecation timeline

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@...ldhost) (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@...ldhost) (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