On Fri, Sep 13, 2024 at 11:08:23AM +0100, Catalin Marinas wrote: > On Thu, Sep 12, 2024 at 02:15:59PM -0700, Charlie Jenkins wrote: > > On Thu, Sep 12, 2024 at 11:53:49AM +0100, Catalin Marinas wrote: > > > On Wed, Sep 11, 2024 at 11:18:12PM -0700, Charlie Jenkins wrote: > > > > Opting-in to the higher address space is reasonable. However, it is not > > > > my preference, because the purpose of this flag is to ensure that > > > > allocations do not exceed 47-bits, so it is a clearer ABI to have the > > > > applications that want this guarantee to be the ones setting the flag, > > > > rather than the applications that want the higher bits setting the flag. > > > > > > Yes, this would be ideal. Unfortunately those applications don't know > > > they need to set a flag in order to work. > > > > It's not a regression, the applications never worked (on platforms that > > do not have this default). The 47-bit default would allow applications > > that didn't work to start working at the cost of a non-ideal ABI. That > > doesn't seem like a reasonable tradeoff to me. If applications want to > > run on new hardware that has different requirements, shouldn't they be > > required to update rather than expect the kernel will solve their > > problems for them? > > That's a valid point but it depends on the application and how much you > want to spend updating user-space. OpenJDK is fine, if you need a JIT > you'll have to add support for that architecture anyway. But others are > arch-agnostic, you just recompile to your target. It's not an ABI > problem, more of an API one. The arch-agnosticism is my hope with this personality flag, it can be added arch-agnostic userspace code and allow the application to work everywhere, but it does have the downside of requiring that change to user-space code. > > The x86 case (and powerpc/arm64) was different, the 47-bit worked for a > long time before expanding it. So it made a lot of sense to keep the > same default. Yes it is very reasonable that this solution was selected for those architectures since the support for higher address spaces evolved in the manner that it did! - Charlie > > Anyway, the prctl() can go both ways, either expanding or limiting the > default address space. So I'd be fine with such interface. > > -- > Catalin
