> * Will Dormann: > - Modern (e.g. 6.x kernel) x86 platforms load a large-enough libc at >> the same address every time. (i.e. no practical ASLR -- "ASLRn't")
For clarity, I'm going use the term "x86_32" to clarify that we're talking about 32-bit architectures & *excluding* the far-more-common 64-bit case. > On Jul 8, 2024, at 1:28 PM, Florian Weimer <fwei...@redhat.com> wrote: > Please note that current glibc is not large enough to benefit from 2 MiB > hugepages because all load segments are smaller than 2 MiB, so it's just > not possible to use hugepages for libc.so.6. This is with the default > -z separate-code in current binutils. Even with -z noseparate-code, the > large readable-executable load segment is still a bit less than 2 MiB. > Unfortunately the kernel does not know this when we reserve the address > space for the entirety of libc.so.6. So clearly there needs to be a way to provide this information :-). > The kernel should not apply hugepage optimizations to mappings created > with MAP_DENYWRITE. Shouldn't that be MAP_EXECUTABLE, not MAP_DENYWRITE? If you use MAP_DENYWRITE, a program that mmaps in a large non-code dataset won't have hugepage optimizations applied, which might be a significant performance regression. Also, the mmap man page: https://man7.org/linux/man-pages/man2/mmap.2.html says that MAP_EXECUTABLE and MAP_DENYWRITE are ignored. There's a risk that some programs are taking that to heart & not using those flags even when they should. If one of those flags *will* have an effect now, then it'd be a good idea to document that :-). --- David A. Wheeler
