public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/19924] TLS performance degradation after dlopen
Date: Fri, 01 Sep 2023 07:22:13 +0000	[thread overview]
Message-ID: <bug-19924-131-q0BNe59BUh@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-19924-131@http.sourceware.org/bugzilla/>

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

--- Comment #28 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Szabolcs Nagy <nsz@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d2123d68275acc0f061e73d5f86ca504e0d5a344

commit d2123d68275acc0f061e73d5f86ca504e0d5a344
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date:   Tue Feb 16 12:55:13 2021 +0000

    elf: Fix slow tls access after dlopen [BZ #19924]

    In short: __tls_get_addr checks the global generation counter and if
    the current dtv is older then _dl_update_slotinfo updates dtv up to the
    generation of the accessed module. So if the global generation is newer
    than generation of the module then __tls_get_addr keeps hitting the
    slow dtv update path. The dtv update path includes a number of checks
    to see if any update is needed and this already causes measurable tls
    access slow down after dlopen.

    It may be possible to detect up-to-date dtv faster.  But if there are
    many modules loaded (> TLS_SLOTINFO_SURPLUS) then this requires at
    least walking the slotinfo list.

    This patch tries to update the dtv to the global generation instead, so
    after a dlopen the tls access slow path is only hit once.  The modules
    with larger generation than the accessed one were not necessarily
    synchronized before, so additional synchronization is needed.

    This patch uses acquire/release synchronization when accessing the
    generation counter.

    Note: in the x86_64 version of dl-tls.c the generation is only loaded
    once, since relaxed mo is not faster than acquire mo load.

    I have not benchmarked this. Tested by Adhemerval Zanella on aarch64,
    powerpc, sparc, x86 who reported that it fixes the performance issue
    of bug 19924.

    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

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

  parent reply	other threads:[~2023-09-01  7:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-19924-131@http.sourceware.org/bugzilla/>
2021-01-26 10:29 ` fweimer at redhat dot com
2021-01-27  1:44 ` cd_songkun at hotmail dot com
2021-01-27 11:26 ` adhemerval.zanella at linaro dot org
2021-02-02 10:36 ` cd_songkun at hotmail dot com
2021-02-17 19:20 ` rwmacleod at gmail dot com
2021-02-23  2:26 ` cd_songkun at hotmail dot com
2021-02-23  2:47 ` carlos at redhat dot com
2021-02-23  2:48 ` carlos at redhat dot com
2021-02-23  8:10 ` thomas.perret+glibc at gresille dot org
2021-02-25  7:31 ` cd_songkun at hotmail dot com
2021-02-25  7:33 ` cd_songkun at hotmail dot com
2021-02-25  7:36 ` cd_songkun at hotmail dot com
2021-02-25  9:54 ` cd_songkun at hotmail dot com
2021-03-24 12:08 ` cd_songkun at hotmail dot com
2021-03-24 15:19 ` carlos at redhat dot com
2021-05-18  2:57 ` cd_songkun at hotmail dot com
2021-05-18 10:12 ` cd_songkun at hotmail dot com
2021-05-18 10:13 ` cd_songkun at hotmail dot com
2021-05-18 13:11 ` adhemerval.zanella at linaro dot org
2021-05-19  8:07 ` cd_songkun at hotmail dot com
2021-06-22 11:01 ` cd_songkun at hotmail dot com
2021-12-08  9:38 ` pgowda.cve at gmail dot com
2023-01-05 16:09 ` zimmerma+gcc at loria dot fr
2023-01-06 10:43 ` nsz at gcc dot gnu.org
2023-07-04 13:55 ` gabravier at gmail dot com
2023-09-01  7:22 ` cvs-commit at gcc dot gnu.org [this message]
2023-09-01  9:32 ` sam at gentoo dot org
2023-09-01  9:32 ` sam at gentoo dot org
2023-09-04 12:13 ` fweimer at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-19924-131-q0BNe59BUh@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).