On Fri, Jan 15, 2021 at 12:09 AM Max Filippov <jcmvbkbc@xxxxxxxxx> wrote:
On Thu, Jan 14, 2021 at 1:25 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
| arch/mips/Kconfig:config HIGHMEM
| arch/xtensa/Kconfig:config HIGHMEM
AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at
most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G
tricks won't work.
Regarding xtensa this was done to minimize difference between
MMUv2 and MMUv3 virtual memory layouts. MMUv2 has been
obsoleted more than 10 years ago, and MMUv3 is much more
flexible and can do e.g. 4GB linear map. The only piece of xtensa
MMUv2 hardware that I have has 96MB of DRAM which fits into
its linear mapping. So maybe it's time to do a cleanup and
rearrange virtual memory layout to eliminate the need of highmem.
Yes, I think that sounds like a useful preparation for the future.
I have no idea who uses xtensa systems with lots of memory on
modern kernels.
We definitely use it for development internally at Cadence/Tensilica,
mainly on simulators, but also on FPGA boards (e.g. on KC705 we
can use all of the 1GB onboard DRAM).
In the last few years we've had a few support requests for linux on
xtensa cores with MMU, but AFAICT none of them had to deal with
more than 512MB of onboard memory.
If 1GB of RAM is a useful upper bound on MMUv3, the easiest way is
probably to hardcode the CONFIG_VMSPLIT_3G_OPT behavior
from x86 and ARM, using 2.75GB of user addresses (TASK_SIZE),
and 1.25 GB that gets split between linear map and vmalloc space,
but no uncached linear map and ioremap() pointing into vmalloc
instead. If you want to be prepared for machines with 2GB of linear
lowmem, you could do the same with VMSPLIT_2G_OPT
(TASK_SIZE == 0x70000000).
Arnd
