On Mon, Aug 26, 2024, at 11:05, Linus Walleij wrote: > On Fri, Aug 23, 2024 at 10:47 PM Vincent Legoll > <vincent.legoll@xxxxxxxxx> wrote: > >> 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. There have been problems in the past with configurations that have a lot less highmem than lowmem, since there is codce that assumes that lowmem is scarce but highmem is not. This means your configuration may have more RAM available when highmem is enabled, but still runs into out-of-memory or other problems more than without highmem. What you see is certainly unrelated to me mentioning that we may remove highmem support from the kernel altogether in the future, but it's possible that OpenWRT turned it off because things work better without it. https://github.com/openwrt/openwrt/issues/13151 may explain what ios going on here. >> 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: > (...) >> The lost RAM is back usable. >> >> Is there an alternative to CONFIG_HIGHMEM to use that RAM chunk ? > > Userspace can still use it right? > > The approach we are taking on ARM32 (despite it's.... really hard) is > to try to create > separate address spaces for the kernel and userspace so that in kernel context > the kernel can use 4GB of memory as it wants without the restriction of userpace > taking up the low addresses. > > This looks easy until you run into some kernel assumptions about memory being > in a linear map at all times. Which I am wrestling with. MIPS32 is a bit special here since it has segments with a fixed mapped, so the linear map is always at a fixed virtual address and at most 512MB in size, where most other architectures can make it e.g. 2GB by changing CONFIG_VMPSPLIT. CONFIG_CPU_MIPS32_3_5_EVA should allow doing this on MIPS as well, but I think the 1004K core in this specific (MT7621) SoC is little too old to support that feature. Arnda
