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

[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]

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.

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

[dzmitry.konanka at karambasecurity dot com]

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

Dzmitry.Konanka <dzmitry.konanka at karambasecurity dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #13482|0                           |1
        is obsolete|                            |

--- Comment #1 from Dzmitry.Konanka <dzmitry.konanka at karambasecurity dot com> ---
Created attachment 13484
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13484&action=edit
FIXED thread local storage benchmark application and suggested glibc patch

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

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

[ville.heikkinen at nokia dot com]

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

Ville Heikkinen <ville.heikkinen at nokia dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ville.heikkinen at nokia dot com

--- Comment #2 from Ville Heikkinen <ville.heikkinen at nokia dot com> ---
I can confirm that we have hit this kind of issue while having a plugin
interface that uses dlopen() to load dynamic libraries. This causes the TLS
performance to degrade significantly. We've tested Dzmitry's patch and it seems
to fix the issue.

Could some of the maintainers check this bug and perhaps we could get the fix
to the upstream?

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