From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id 65A823857C7D for ; Tue, 12 Jul 2022 19:19:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 65A823857C7D Received: by mail-oi1-x233.google.com with SMTP id p132so5610342oif.9 for ; Tue, 12 Jul 2022 12:19:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uYkcPHrZrVc+/b4pW/6G1TwlVjDGdmN6XhGWMCnoCIk=; b=Xd2+Ghu+pGWEmJURbk1FAPCI/H848CD6Cs6+Cw4uLg0KDg9FwgHoxpse3vuLQ/MD0l FOWNY5lO7HE+x/bBeWMmwR7b14drBydAY7X6KoEWYdSBNYxXwpHkV7nFbVbcLzBa6eDN HNdVgHRkrRpJePzdNHvBwlHx+DBXPXKwHuVr38pth6+ISjhxX4t2R3yuw7p5B4hAFdue gGDaHKGlkXuc8fLOV7JJGrmswpecDJLgczsTOxJB5U/bAaoAZxhJqQxxEVxoxzFvfM30 v7C5uElyF5c1Uj7Q7RhrUQddwWb/IPNpR+jFveDzjLz2ms0wlbDzVhn9sQXJK8iQs51C 8uEQ== X-Gm-Message-State: AJIora8I+iYWg3sGRDg7Eg7RDJSJN4jpEcnjNNbKu/G0rolsGSmhCQNx 9aHWtIRrkGkAie7IN5hdtyrzg8Y3qUoWkn3tRXk= X-Google-Smtp-Source: AGRyM1s7R5XHCAFitZMYdmaLscu5TG3NtK/6RExpvvXJKya0XUjg/kgdycPUEMNigGBmXb+lXkBKynguuHrPEgogXjU= X-Received: by 2002:a05:6808:170b:b0:335:1807:e4a2 with SMTP id bc11-20020a056808170b00b003351807e4a2mr2689671oib.89.1657653541840; Tue, 12 Jul 2022 12:19:01 -0700 (PDT) MIME-Version: 1.0 References: <0f40a803-eb51-e803-edd3-e6cf05a97b74@linaro.org> In-Reply-To: From: Noah Goldstein Date: Tue, 12 Jul 2022 12:18:50 -0700 Message-ID: Subject: Re: [PATCH 3/7] Remove atomic_bit_set/bit_test_set To: "H.J. Lu" Cc: Wilco Dijkstra , Adhemerval Zanella Netto , GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 19:19:03 -0000 On Tue, Jul 12, 2022 at 12:11 PM H.J. Lu wrote: > > On Tue, Jul 12, 2022 at 11:44 AM Wilco Dijkstra wrote: > > > > Hi, > > > > I don't believe it could make a difference since it isn't performance critical code. > > Note that several similar fetch_or/fetch_and are used which do not optimize into a > > Only the operations with test have this issue. Simple fetch_or and > fetch_and are > OK. > > > bitset operation, so even if we fix this particular case to use unsigned, there are many > > others. IIRC there is even a fetch_or with zero which is kind of useless! > > > > More importantly, it raises a question for locking: we currently use a compare-exchange > > for each lock and unlock. If compare-exchange has higher overheads than other atomics > > then we should investigate more efficient locking sequences. > > compare-exchange can be very expensive under contention. > Which locks should we look into dropping CAS? pthread_mutex? Anything else? > > Cheers, > > Wilco > > > > -- > H.J.