On 11/21/2016 07:51 AM, Christopher Covington wrote: > On 11/18/2016 05: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: >> >> ffffacbb0000-ffffacbc0000 r-xp 00000000 103:04 33858952 /usr/lib64/libnss_files-2.17.so >> ffffacbc0000-ffffacbd0000 r--p 00000000 103:04 33858952 /usr/lib64/libnss_files-2.17.so >> ffffacbd0000-ffffacbe0000 rw-p 00010000 103:04 33858952 /usr/lib64/libnss_files-2.17.so >> ffffacbf0000-ffffacc30000 r-xp 00000000 103:04 33644605 /usr/lib64/libpcre.so.1.2.0 >> ffffacc30000-ffffacc40000 r--p 00030000 103:04 33644605 /usr/lib64/libpcre.so.1.2.0 >> ffffacc40000-ffffacc50000 rw-p 00040000 103:04 33644605 /usr/lib64/libpcre.so.1.2.0 > > How does GNU ld determine VA bits? Hi, AFAIK, It doesn't, at least for library placement. The run-time linker uses unspecified mmap() to place the libraries/sections (with appropriate flags) and the kernel chooses/reuses the placement.