Message ID | 20210830152636.1334678-1-bugaevc@gmail.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 756423858417 for <patchwork@sourceware.org>; Mon, 30 Aug 2021 15:27:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 756423858417 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1630337277; bh=kWIWOufDKGo394XDsz1+hHwGIWtayySjOg8grlKye+0=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=Pl3lZ/qHJC3qUsNbRBSyCiUoQ2KDD7P20UoCqrU+k2C3zGjrMiGKHGBWBPMRzs+fZ W/hXfesUaHbrU9CUPUjU5L6N8nVygrhkI5JfGJokozsNVzz+sMhFkgM9+9jv843rRk VJnr71aqOlEDyUSe8gxelQ4zZMgXneaKqObLwt2s= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 6294D3858417 for <libc-alpha@sourceware.org>; Mon, 30 Aug 2021 15:26:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6294D3858417 Received: by mail-lf1-x133.google.com with SMTP id k5so32051801lfu.4 for <libc-alpha@sourceware.org>; Mon, 30 Aug 2021 08:26:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=kWIWOufDKGo394XDsz1+hHwGIWtayySjOg8grlKye+0=; b=l10uGg5s+6N+B4XLCBez+Xm5LyjWTPl5XIWyHev2QpugiFpFTDZxzIA67+IQcRtq2S nYEiOqWhFFEw5HjvYHpiPTNjeaOstZv8sVAaFxedOfGMH14D1JyKuoMioyENXMnUEAmd UB6+SMy06EiLl3u/KramlujCRit38OdHsHfYAzUHui9IiRk2VklrZQ9DEPapGTBjQZ0M I6jt1FyGuh3u5dd73ZkLL/NxfSXF5fSbS8rQw3E4OZE+8vNV+/hCUHhBiY7FF0RdNbop IlttC866My1F4TjCZjgw3cimQHnKwS4wT+WoiftlJ9LtpCyUXo+jvS9MDMV4jAdIkyVJ vbgg== X-Gm-Message-State: AOAM533V/v7o1n03j8xQeIEFHmdVhf0Ud1PVCVTBUJD3bpoVLHLo6tDr 8K7RK/lJ+G6UQZa+ZrP8pCf91bMZqT59ZUR/ X-Google-Smtp-Source: ABdhPJwojn4t4T7IM5XcK1qULUiSCjeMzi4XgzxlrPq3MjjgCQxl0/IIkVGzDGdOCjk/vAXUEYfzVg== X-Received: by 2002:a19:c1c3:: with SMTP id r186mr17246580lff.609.1630337208702; Mon, 30 Aug 2021 08:26:48 -0700 (PDT) Received: from badwolf.office.smartdec.ru ([81.23.5.115]) by smtp.googlemail.com with ESMTPSA id b18sm1882314ljk.24.2021.08.30.08.26.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Aug 2021 08:26:48 -0700 (PDT) To: libc-alpha@sourceware.org, bug-hurd@gnu.org Subject: [RFC PATCH htl v2 0/4] Rewrite THREAD_GSCOPE Date: Mon, 30 Aug 2021 18:26:32 +0300 Message-Id: <20210830152636.1334678-1-bugaevc@gmail.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Sergey Bugaev via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Sergey Bugaev <bugaevc@gmail.com> Cc: samuel.thibault@gnu.org, Sergey Bugaev <bugaevc@gmail.com> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series | Rewrite THREAD_GSCOPE | |
Message
Sergey Bugaev
Aug. 30, 2021, 3:26 p.m. UTC
Hello, this is a revised version of the patchset I have sent a few months ago [0]. Sending to both bug-hurd and libc-alpha this time. [0]: https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00063.html The goal is to get rid of the excessive (and redundant) gsync_wake () calls. The means are rewriting how THREAD_GSCOPE_* is implemented in HTL to work more like its NPTL counterpart. To get this working, I first have to expose HTL's internal thread table to ld.so, a lot like NPTL already does. Before this patchset: $ rpctrace uname |& grep -c gsync_wake 57 With this patchset (first 3 patches): $ ./testrun.sh --tool=rpctrace /bin/uname |& grep -c gsync_wake 0 The unsolved question with this patchset is the fate of THREAD_GSCOPE_IN_TCB. Apparently, when it was introduced in [1], it was indeed only used to distinguish between cases where the GSCOPE flag is in TCB or not. But as of now, it is used mostly as a generic way to conditionally compile either HTL- or NPTL-specific code, mostly for TLS initialization. Now that all ports have the GSCOPE flag in TCB, this definition no longer does what it says. [1]: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a5df0318ef30a4dcff3fa2cb82265f641813d9ea I can think of two ways this can be handled: * Code can be rewritten and reorganized to use port-specific files instead of conditional compilation. From looking at how glibc source is organized, this appears to be the generally preferred way. I'm sending one more patch that makes a (perhaps misguided) attempt to do this; but I'm not sure what would be good way to handle the definitions in <ldsodefs.h> -- please take a look. * A more conservative approach would be to leave the code using THREAD_GSCOPE_IN_TCB as is for now, but change the variable's name to better reflect what it's used for. I haven't really been able to come up with a good name, though. Alternatively, it could just be left as is for now. Sergey Bugaev (4): htl: Move thread table to ld.so htl: Reimplement GSCOPE testrun.sh: Add support for --tool=rpctrace XXX: Attempt to get rid of most THREAD_GSCOPE_IN_TCB usages Makefile | 9 +++- elf/dl-reloc.c | 21 --------- elf/dl-support.c | 15 ------ elf/dl-tls.c | 39 --------------- htl/Versions | 2 - htl/pt-alloc.c | 50 ++++++++------------ htl/pt-create.c | 11 ++--- htl/pt-internal.h | 23 +++------ sysdeps/generic/ldsodefs.h | 10 ++-- sysdeps/htl/dl-support.c | 28 +++++++++++ sysdeps/htl/dl-thread_gscope_wait.c | 55 ++++++++++++++++++++++ sysdeps/htl/dl-tls.c | 39 +++++++++++++++ {elf => sysdeps/htl}/dl-tls_init_tp.c | 4 +- sysdeps/htl/pt-key-delete.c | 8 ++-- sysdeps/htl/pthreadP.h | 2 - sysdeps/htl/raise.c | 8 +++- sysdeps/htl/thrd_current.c | 7 ++- sysdeps/mach/hurd/htl/pt-sigstate-init.c | 2 +- sysdeps/mach/hurd/htl/pt-sysdep.c | 2 +- sysdeps/mach/hurd/htl/pt-sysdep.h | 2 +- sysdeps/mach/hurd/i386/tls.h | 19 ++++++++ sysdeps/mach/hurd/tls.h | 20 +------- sysdeps/nptl/dl-support.c | 26 ++++++++++ sysdeps/nptl/dl-tls.c | 53 +++++++++++++++++++++ sysdeps/unix/sysv/linux/alpha/dl-support.c | 2 +- 25 files changed, 287 insertions(+), 170 deletions(-) create mode 100644 sysdeps/htl/dl-support.c create mode 100644 sysdeps/htl/dl-thread_gscope_wait.c create mode 100644 sysdeps/htl/dl-tls.c rename {elf => sysdeps/htl}/dl-tls_init_tp.c (93%) create mode 100644 sysdeps/nptl/dl-support.c create mode 100644 sysdeps/nptl/dl-tls.c
Comments
* Sergey Bugaev: > I can think of two ways this can be handled: > > * Code can be rewritten and reorganized to use port-specific files instead of > conditional compilation. From looking at how glibc source is organized, this > appears to be the generally preferred way. I'm sending one more patch that > makes a (perhaps misguided) attempt to do this; but I'm not sure what would > be good way to handle the definitions in <ldsodefs.h> -- please take a look. Yes, that's usually how things are done. > * A more conservative approach would be to leave the code using > THREAD_GSCOPE_IN_TCB as is for now, but change the variable's name to > better reflect what it's used for. I haven't really been able to come > up with a good name, though. You could kick the can down the road by switching to PTHREAD_IN_LIBC. In some cases, that might actually be correct replacement. Thanks, Florian
Thanks for looking into it! On Mon, Aug 30, 2021 at 6:37 PM Florian Weimer <fweimer@redhat.com> wrote: > You could kick the can down the road by switching to PTHREAD_IN_LIBC. > In some cases, that might actually be correct replacement. Ack; that should be easy to do. Nevertheless, please do look at patch 4/4 and say if you would prefer that approach. Do you happen to know if there's a testcase that exercises THREAD_GSCOPE_WAIT ()? Even simple programs evidently use THREAD_GSCOPE_SET_FLAG () / THREAD_GSCOPE_RESET_FLAG (), but I so far haven't been able to construct a program that would trigger the WAIT. I've tried dlopening and dlclosing libraries concurrently from several threads; I will try dlopening hundreds of libraries next (to hopefully trigger a reallocation of some table), but it would be handy if there was an official ready-to-use testcase. Sergey