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
