[Arm-dev] [PATCH v2] config-centos-sig: aarch64: Enable 48 bit VA

[Jeremy Linton]

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.