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.
Signed-off-by: Jeremy Linton jeremy.linton@arm.com --- SOURCES/config-centos-sig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/SOURCES/config-centos-sig b/SOURCES/config-centos-sig index 15f60f4..33486a9 100644 --- a/SOURCES/config-centos-sig +++ b/SOURCES/config-centos-sig @@ -9,4 +9,6 @@ CONFIG_XGENE_PMU=y CONFIG_I2C_DESIGNWARE_CORE=m CONFIG_I2C_DESIGNWARE_PLATFORM=m CONFIG_I2C_DESIGNWARE_PCI=m +CONFIG_ARM64_VA_BITS_48=y +CONFIG_ARM64_VA_BITS=48
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
Signed-off-by: Jeremy Linton jeremy.linton@arm.com
SOURCES/config-centos-sig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/SOURCES/config-centos-sig b/SOURCES/config-centos-sig index 15f60f4..33486a9 100644 --- a/SOURCES/config-centos-sig +++ b/SOURCES/config-centos-sig @@ -9,4 +9,6 @@ CONFIG_XGENE_PMU=y CONFIG_I2C_DESIGNWARE_CORE=m CONFIG_I2C_DESIGNWARE_PLATFORM=m CONFIG_I2C_DESIGNWARE_PCI=m +CONFIG_ARM64_VA_BITS_48=y +CONFIG_ARM64_VA_BITS=48
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?
Thanks, Cov
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.
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.
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.
-
Christopher Covington -
Jeremy Linton -
Jeremy Linton -
Jim Perrin