On Fri, Sep 6, 2024, at 09:14, Guo Ren wrote:
On Fri, Sep 6, 2024 at 3:18 PM Arnd Bergmann arnd@arndb.de wrote:
It's also unclear to me how we want this flag to interact with the existing logic in arch_get_mmap_end(), which attempts to limit the default mapping to a 47-bit address space already.
To optimize RISC-V progress, I recommend:
Step 1: Approve the patch. Step 2: Update Go and OpenJDK's RISC-V backend to utilize it. Step 3: Wait approximately several iterations for Go & OpenJDK Step 4: Remove the 47-bit constraint in arch_get_mmap_end()
I really want to first see a plausible explanation about why RISC-V can't just implement this using a 47-bit DEFAULT_MAP_WINDOW like all the other major architectures (x86, arm64, powerpc64), e.g. something like the patch below (untested, probably slightly wrong but show illustrate my point).
Arnd
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h index 8702b8721a27..de9863be1efd 100644 --- a/arch/riscv/include/asm/processor.h +++ b/arch/riscv/include/asm/processor.h @@ -20,17 +20,8 @@ * mmap_end < addr, being mmap_end the top of that address space. * See Documentation/arch/riscv/vm-layout.rst for more details. */ -#define arch_get_mmap_end(addr, len, flags) \ -({ \ - unsigned long mmap_end; \ - typeof(addr) _addr = (addr); \ - if ((_addr) == 0 || is_compat_task() || \ - ((_addr + len) > BIT(VA_BITS - 1))) \ - mmap_end = STACK_TOP_MAX; \ - else \ - mmap_end = (_addr + len); \ - mmap_end; \ -}) +#define arch_get_mmap_end(addr, len, flags) \ + (((addr) > DEFAULT_MAP_WINDOW) ? TASK_SIZE : DEFAULT_MAP_WINDOW)
#define arch_get_mmap_base(addr, base) \ ({ \ @@ -47,7 +38,7 @@ })
#ifdef CONFIG_64BIT -#define DEFAULT_MAP_WINDOW (UL(1) << (MMAP_VA_BITS - 1)) +#define DEFAULT_MAP_WINDOW (is_compat_task() ? (UL(1) << (MMAP_VA_BITS - 1)) : TASK_SIZE_32) #define STACK_TOP_MAX TASK_SIZE_64 #else #define DEFAULT_MAP_WINDOW TASK_SIZE