[Bug dynamic-link/27944] New: poor TLS performance in shared object after calling dlopen with another shared object that also contains TLS section

["dzmitry.konanka at karambasecurity dot com" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 27944
           Summary: poor TLS performance in shared object after calling
                    dlopen with another shared object that also contains
                    TLS section
           Product: glibc
           Version: 2.28
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: dzmitry.konanka at karambasecurity dot com
  Target Milestone: ---

Created attachment 13482
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13482&action=edit
thread local storage benchmark application and suggested glibc patch

Performance of accessing __thread variables is degraded in following scenario:
- __thread variable defined in shared object.
- dlopen invoked to load another shared object that has TLS section.
In this scenario synthetic benchmark application shown more than twice
performance degradation. Futher analyzis with gdb shown that each access to TLS
variable causes _dl_update_slotinfo to be called due to following condition
inside of __tls_get_addr always evaluates as true: if (__glibc_unlikely
(dtv[0].counter != GL(dl_tls_generation))) that doesn't look as designed
behavior.
Problem tested and found on x86-64 and ARM with glibc 2.19, 2.25, 2.27, 2.28
and likely will happen with recent glibc too.
I've made simple workaround that fixes problem, however i'm not sure in its
100% validity since related code is a little bit complicated. But at least it
confirms guessed problem's reason.
Both benchmark app and suggested glibc patch are inside of attached archive.
There you can also find readme.txt with info how to use benchmark.

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