On Wed, Jul 22, 2020 at 1:23 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote: > > On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote: > > > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote: > > > The eventual goal is to have a split of 3840MB for either user or linear map > > > plus and 256MB for vmalloc, including the kernel. Switching between linear > > > and user has a noticeable runtime overhead, but it relaxes both the limits > > > for user memory and lowmem, and it provides a somewhat stronger > > > address space isolation. > > > > Ya, I think we decided not to do that, at least for now. I guess the right > > answer there will depend on what 32-bit systems look like, and since we don't > > have any I'm inclined to just stick to the fast option. > > Makes sense. Actually on 32-bit Arm we see fewer large-memory > configurations in new machines than we had in the past before 64-bit > machines were widely available at low cost, so I expect not to see a > lot new hardware with more than 1GB of DDR3 (two 256Mbit x16 chips) > for cost reasons, and rv32 is likely going to be similar, so you may never > really see a need for highmem or the above hack to increase the > size of the linear mapping. > > I just noticed that rv32 allows 2GB of lowmem rather than just the usual > 768MB or 1GB, at the expense of addressable user memory. This seems > like an unusual choice, but I also don't see any reason to change this > or make it more flexible unless actual users appear. > I am a bit confused here. As per my understanding, RV32 supports 1GB of lowmem only as the page offset is set to 0xC0000000. The config option MAXPHYSMEM_2GB is misleading as RV32 actually allows 1GB of physical memory only. Any memory blocks beyond DRAM + 1GB are removed in setup_bootmem. IMHO, The current config should clarify that. Moreover, we should add 2G split under a separate configuration if we want to support that. > Arnd > > _______________________________________________ > linux-riscv mailing list > linux-riscv@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish
