On Sat, May 20, 2023 at 12:54 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Fri, May 19, 2023, at 17:31, Guo Ren wrote: > > On Fri, May 19, 2023 at 2:29 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> On Thu, May 18, 2023, at 17:38, Palmer Dabbelt wrote: > >> > On Thu, 18 May 2023 06:09:51 PDT (-0700), guoren@xxxxxxxxxx wrote: > >> > >> If for some crazy reason you'd still want the 64ilp32 ABI in user > >> space, running the kernel this way is probably still a bad idea, > >> but that one is less clear. There is clearly a small memory > >> penalty of running a 64-bit kernel for larger data structures > >> (page, inode, task_struct, ...) and vmlinux, and there is no > > I don't think it's a small memory penalty, our measurement is about > > 16% with defconfig, see "Why 32-bit Linux?" section. > > > > This patch series doesn't add 64ilp32 userspace abi, but it seems you > > also don't like to run 32-bit Linux kernel on 64-bit hardware, right? > > Ok, I'm sorry for missing the important bit here. So if this can > still use the normal 32-bit user space, the cost of this patch set > is not huge, and it's something that can be beneficial in a few > cases, though I suspect most users are still better off running > 64-bit kernels. > > > The motivation of s64ilp32 (running 32-bit Linux kernel on 64-bit s-mode): > > - The target hardware (Canaan Kendryte k230) only supports MXL=64, > > SXL=64, UXL=64/32. > > - The 64-bit Linux + compat 32-bit app can't satisfy the 64/128MB scenarios. > > > >> huge additional maintenance cost on top of the ABI itself > >> that you'd need either way, but using a 64-bit address space > >> in the kernel has some important advantages even when running > >> 32-bit userland: processes can use the entire 4GB virtual > >> space, while the kernel can address more than 768MB of lowmem, > >> and KASLR has more bits to work with for randomization. On > >> RISCV, some additional features (VMAP_STACK, KASAN, KFENCE, > >> ...) depend on 64-bit kernels even though they don't > >> strictly need that. > > > > I agree that the 64-bit linux kernel has more functionalities, but: > > - What do you think about linux on a 64/128MB SoC? Could it be > > affordable to VMAP_STACK, KASAN, KFENCE? > > I would definitely recommend VMAP_STACK, but that can be implemented > and is used on other 32-bit architectures (ppc32, arm32) without a > huge cost. The larger virtual user address space can help even on > machines with 128MB, though most applications probably don't care at > that point. Good point, I would support VMAP_STACK in ARCH_RV64ILP32. > > > - I think 32-bit Linux & RTOS have monopolized this market (64/128MB > > scenarios), right? > > The minimum amount of RAM that makes a system usable for Linux is > constantly going up, so I think with 64MB, most new projects are > already better off running some RTOS kernel instead of Linux. > The ones that are still usable today probably won't last a lot > of distro upgrades before the bloat catches up with them, but I > can see how your patch set can give them a few extra years of > updates. Linux development costs much cheaper than RTOS, so the vendors would first develop a Linux version. If it succeeds in the market, the vendors will create a cost-down solution. So their first choice is to cut down the memory footprint of the first Linux version instead of moving to RTOS. With the price of 128MB-DDR3 & 64MB-DDR2 being more and more similar, 32bit-Linux has more opportunities to instead of RTOS. > > For the 256MB+ systems, I would expect the sensitive kernel > allocations to be small enough that the series makes little > difference. The 128MB systems are the most interesting ones > here, and I'm curious to see where you spot most of the > memory usage differences, I'll also reply to your initial > mail for that. Thx, I aslo recommand you read about "Why s64ilp32 has better performance?" section :) How do you think running arm32-Linux on coretex-A35/A53/A55? > > Arnd -- Best Regards Guo Ren
