On Thu, Sep 05, 2024 at 10:26:52AM -0700, Charlie Jenkins wrote:
On Thu, Sep 05, 2024 at 09:47:47AM +0300, Kirill A. Shutemov wrote:
On Thu, Aug 29, 2024 at 12:15:57AM -0700, Charlie Jenkins wrote:
Some applications rely on placing data in free bits addresses allocated by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the address returned by mmap to be less than the 48-bit address space, unless the hint address uses more than 47 bits (the 48th bit is reserved for the kernel address space).
The riscv architecture needs a way to similarly restrict the virtual address space. On the riscv port of OpenJDK an error is thrown if attempted to run on the 57-bit address space, called sv57 [1]. golang has a comment that sv57 support is not complete, but there are some workarounds to get it to mostly work [2].
I also saw libmozjs crashing with 57-bit address space on x86.
These applications work on x86 because x86 does an implicit 47-bit restriction of mmap() address that contain a hint address that is less than 48 bits.
Instead of implicitly restricting the address space on riscv (or any current/future architecture), a flag would allow users to opt-in to this behavior rather than opt-out as is done on other architectures. This is desirable because it is a small class of applications that do pointer masking.
You reiterate the argument about "small class of applications". But it makes no sense to me.
With full address space by default, this small class of applications is going to *broken* unless they would handle RISC-V case specifically.
On other hand, if you limit VA to 128TiB by default (like many architectures do[1]) everything would work without intervention. And if an app needs wider address space it would get it with hint opt-in, because it is required on x86-64 anyway. Again, no RISC-V-specific code.
I see no upside with your approach. Just worse user experience.
[1] See va_high_addr_switch test case in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool...