lkml.org 
[lkml]   [2023]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH 00/22] riscv: s64ilp32: Running 32-bit Linux kernel on 64-bit supervisor mode
    On Sat, May 20, 2023 at 12:54 AM Arnd Bergmann <arnd@arndb.de> wrote:
    >
    > On Fri, May 19, 2023, at 17:31, Guo Ren wrote:
    > > On Fri, May 19, 2023 at 2:29 AM Arnd Bergmann <arnd@arndb.de> wrote:
    > >> On Thu, May 18, 2023, at 17:38, Palmer Dabbelt wrote:
    > >> > On Thu, 18 May 2023 06:09:51 PDT (-0700), guoren@kernel.org 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

    \
     
     \ /
      Last update: 2023-05-20 03:44    [W:2.924 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site