Hi, On 11/21/2016 11:44 AM, Jim Perrin wrote: > > > On 11/18/2016 04:34 PM, Jeremy Linton wrote: >> On 11/18/2016 04:29 PM, Jeremy Linton wrote: >>> The current RHELSA kernel is using a 42bit VA which >>> is too limiting for possible near future workloads. >>> Update this to 48 bits. This patch has a dependency >>> on mozjs versions in the distro being patched to >>> work with virtual address spaces >47 bits. >> >> Just a quick comment. An easy way to verify that the kernel in use has >> 48bit VA's is to check the /proc/xxx/maps of a userspace process. >> >> A 48bit VA kernel will place shared libraries into addresses at the top >> of the userspace address region. For example: >> > > > In thinking about this a bit more, I'd like to hold off on merging the > 48bit VA patches in for the initial install kernel so that we have time > to discuss the potential implications a bit more. We can always > merge/push it as an update once we're a bit more clear on the impact of > the fixes. That is understandable, but I think a lot has been made out of what is a fairly small change. The robustness of the kernel & linker, with respect to varying the VA is evident by all the different choices that have existed (cross platform/etc) and the nearly complete lack of issues. The only actual issues have been seen by applications placing tag bits into virtual address bits which are now being used. So, far that has been a couple of JIT/Interpreters that are trying to save the overhead of a couple bits of metadata by encoding it into the pointers to the actual objects. The most notable has been mozjs, particularly because its not an official system dependency due to the use by polkitd and gnome for core pieces of functionality.