-
Bug
-
Resolution: Done-Errata
-
Normal
-
rhel-8.5.0
-
glibc-2.28-238.el8
-
None
-
Moderate
-
rhel-sst-pt-libraries
-
ssg_platform_tools
-
2
-
QE ack, Dev ack
-
False
-
-
Yes
-
None
-
Pass
-
None
-
Bug Fix
-
-
Done
-
-
x86_64
-
None
Description of problem: When two separate threads load TLS library functions sequentially, one thread will be very slow due to a generation counter mismatch (and thus glibc thinking it needs to reallocate memory for it).
Version-Release number of selected component (if applicable):
2.28-164.el8.x86_64
How reproducible: 100%
Steps to Reproduce:
1. yum install gcc gcc-c++ make glibc-devel openssl-devel
2. Unzip shell archive with test case.
3. Run "make".
4. Execute program "tls-test".
Actual results:
One thread is slower than the other to access TLS variables:
none loaded
main normal variable : 554.770ms
main thread-local variable : 578.829ms
lib1 loaded
main normal variable : 536.941ms
main thread-local variable : 504.300ms
lib1 variable : 2079.362ms
lib2 loaded
main normal variable : 451.575ms
main thread-local variable : 434.603ms
lib1 variable : 5567.543ms
lib2 accessed
main normal variable : 424.644ms
main thread-local variable : 429.140ms
lib1 variable : 1911.933ms
Expected results: lib1 variable access time is consistent.
Additional info:
- Issue was first noted in 2016 (https://patchwork.ozlabs.org/project/glibc/patch/1465309688.1188.19.camel@mailbox.tu-dresden.de/), and a patch was proposed.
- causes
-
RHEL-39994 glibc: Add workaround for certain dynamic TLS usage in interposed malloc [rhel-8.10.z]
- Closed
- is cloned by
-
RHEL-2123 glibc: TLS performance degradation when loading two or more threads [rhel-9.4]
- Closed
- is triggering
-
RHEL-17468 glibc: Corrupt DTV after reuse of a TLS module ID following dlclose with unused TLS [rhel-8.10]
- Closed
- external trackers
- links to
-
RHBA-2023:122573 glibc bug fix and enhancement update
- mentioned on