[Bug ld/26925] New: x86/ld: Performance regression with execl()

[yummypeng at linux dot alibaba.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26925

            Bug ID: 26925
           Summary: x86/ld: Performance regression with execl()
           Product: binutils
           Version: 2.31
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: yummypeng at linux dot alibaba.com
  Target Milestone: ---

With the following commit introduced in ld-2.31:
```
Author: H.J. Lu <hjl.tools@gmail.com>
Branch: master
Commit: f6aec96dce1ddbd8961a3aa8a2925db2021719bb

ld: Add --enable-separate-code

This patch adds --enable-separate-code to ld configure to turn on
-z separate-code by default and enables it by default for Linux/x86.
This avoids mixing code pages with data to improve cache performance
as well as security.

To reduce x86-64 executable and shared object sizes, the maximum page
size is reduced from 2MB to 4KB when -z separate-code is turned on by
default.  Note: -z max-page-size= can be used to set the maximum page
size.

We compared SPEC CPU 2017 performance before and after this change on
Skylake server.  There are no any significant performance changes.
Everything is mostly below +/-1%.
```

I find that binaries linked by ld-2.31 contain more program headers than
before. Further, if I use ld-2.31 while compiling glibc, then every executable
and dynamic library contains more program headers, which results to more mmap()
calls when loading these dynamic libraries.

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.