https://sourceware.org/bugzilla/show_bug.cgi?id=26925
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com
--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to yummypeng from comment #0)
>
> I have two vm, one with glibc linked with ld-2.31 and another with glibc
> linked with ld-2.30. Take the /lib64/libpthread.so.0 for example:
>
> - glibc linked with ld-2.30:
> ```
> $ readelf -l /lib64/libpthread.so.0
>
> Elf file type is DYN (Shared object file)
> Entry point 0x6d80
> There are 9 program headers, starting at offset 64
> ```
>
> - glibc linked with ld-2.31:
> ```
> $ readelf -l /lib64/libpthread.so.0
>
> Elf file type is DYN (Shared object file)
> Entry point 0x8200
> There are 13 program headers, starting at offset 64
> ```
>
> This causes performance regression (nearly 40%) of execl unixbench. By
> tracing the test routine, I can see more mmap() calls with every loading of
> dynamic libraries.
This is done on purpose. If only things you do is loading shared libraries,
there will be more mmap calls. But since loading shared libraries takes a
small percentage of execution time for most applications, it isn't an issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
