Re: [PATCH 1/2] RISC-V: mm: Restrict address space for sv39,sv48,sv57

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 28, 2023 at 06:04:41PM +0530, Anup Patel wrote:
> On Wed, Jun 28, 2023 at 5:09 AM Charlie Jenkins <charlie@xxxxxxxxxxxx> wrote:
> >
> > Yes it is small to have a default of 38-bits of userspace. I would be
> > interesting in the opinions of other people on whether it would be
> > acceptable to have the default be sv48 and require applications that
> > prefer fewer bits to specify so with the given mmap hinting.
> 
> I think sv48 is a reasonable default instead of sv39. We should fallback
> to sv39 only if the underlying host does not support sv48.
> 
> Regards,
> Anup

I did some research and it appears that Java does work on sv48, but not
on sv57. Using the v6.4 kernel I was able to successfully run OpenJDK on
both sv38 and sv48, but on sv57 there is a SIGSEGV error on QEMU.
Relevant JDK discussion can be seen here 
https://mail.openjdk.org/pipermail/hotspot-dev/2022-November/067298.html.
Go similarly appears to work even on sv57 according to https://go-review.googlesource.com/c/go/+/409055.
I have not tried Go myself. 

The point of contention here I believe is that in v6.4, the highest
address space available will be used, causing all of these applications
that do not work properly in sv57 to fail when testing in sv57
environments. Given that these applications seem to work in sv48, it
seems reasonable to default to sv48, unless there are an abundance of
additional applications that are unhappy with this.

Using the hint mechanism to mmap will then allow users to change the
address space to sv57 if required. It should be possible to allow users
to use sv38 if they need it using the same mechanism, but reducing the
address space instead of growing it will require more thought from me to
implement.

Thanks,
Charlie



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux