From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 597A5385840E for ; Fri, 24 Nov 2023 16:29:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 597A5385840E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 597A5385840E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700843348; cv=none; b=QT5XtAlo/VzQVR8WWTT2F6DQBXDyAzkQCjP/lJ6QUxLb8MBX8vogiKDYPMMtyO3AB5h0pI8i6dHmTEFotevN8DBwykGG6ff7RmOQogavi9OtdsV1jj2fhiR0ka/LjQwdQmZilfyauD+izYtj4F7L25g+6ofRBK8JCWrzzAv8G1E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700843348; c=relaxed/simple; bh=/W1RNdchMwrLRY+CQS3nDo+tAZLPScTFLaVtXM27YUY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=qy58P2I7yB/4iKQ7I1Sxrz6JywbL/528h+eWSOTmkyLQMsHjnb2MXcZTzLXEavnkiNfb42fWZV0Ci5kfVKmlbFnCEw/Oq1dTXDZ/eovSTBsFJiKkNM/so5nQel3csgJsKpr+7Op2wmWqxRlfHavp3SZ3Xf4HWPx/ONM1ijxN2E0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700843347; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CLts62XTCBAeWf250LqLqwVvXTRRRKPNdK5vTLdqxKo=; b=amX3j728ePPTuNDZsc7GUEvnDOd3Y0aGhMniPvPrO0uKGfgyYffoXe6vHqFqd+GvkDT7ga 8+Jll9voDW5gmrU21VT1sbI5Id6cmvjyyYVb/4pYAJzv9XrVdbZBqJp8ZqXRpP0cUpYjcV jA1cb98idEp0k7Q0umEvBd40YMQ9V/A= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-416-2vKlskOdPHGyDV1VBrbMaQ-1; Fri, 24 Nov 2023 11:29:05 -0500 X-MC-Unique: 2vKlskOdPHGyDV1VBrbMaQ-1 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-77d55e875aaso228398685a.3 for ; Fri, 24 Nov 2023 08:29:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700843345; x=1701448145; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CLts62XTCBAeWf250LqLqwVvXTRRRKPNdK5vTLdqxKo=; b=tutC5im0j9w0vweGaf8EKwYMG1x+XUjEnGrvMX5XN7iLFVfem30qUlc+eGXXrL6OkU 86ckZWEoVF4e38SR4FkLkd9701fzl17xF8xH/VsFg4TKHxrcJrE/ngnZ15hmgh2V6wJV eYO4VsHUuLxRURHgHXw7TdowlgUF8tJmiIOIfcbO7MYlEql2UODegu0zcxKGTPI2zJer uwGUXeZzTUVWPhuQy1J5Xcp6Jm1RNARqe7J9ORU7Q+UvF7EQlS76+GEVZNSGgE7O3OFK 3CgN3qW57xZb76xCwjr2tiNBa5GapyY7Wbl7cnJM7WGicMJVCL2lgZuTXvlOeY1aKftw x81w== X-Gm-Message-State: AOJu0YzA0xLz3ruKvl8iwdcV0olHdvEBKimLHyJzL5PsMOYwC+ketxM+ zyuuJHmNfSW0/wT5VIGi5NGtkXdougl5iRi9b5ohSeA5HzEbSUQeV1Zi0BMRQxpAF85KcMbo+UM N+28PUb7GplazszivnNvT X-Received: by 2002:a05:620a:1323:b0:775:f1bd:f75e with SMTP id p3-20020a05620a132300b00775f1bdf75emr3503978qkj.39.1700843345384; Fri, 24 Nov 2023 08:29:05 -0800 (PST) X-Google-Smtp-Source: AGHT+IEWxZd7QC3Rb2HuBBPZpwvvksoazhq19txnJlyTz5/60HLxk3N4RZ8bRQuWWvJGFUoEOqQz7A== X-Received: by 2002:a05:620a:1323:b0:775:f1bd:f75e with SMTP id p3-20020a05620a132300b00775f1bdf75emr3503957qkj.39.1700843345133; Fri, 24 Nov 2023 08:29:05 -0800 (PST) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id y21-20020a05620a25d500b00763b94432ebsm1339400qko.18.2023.11.24.08.29.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Nov 2023 08:29:04 -0800 (PST) Message-ID: <89f0615a-d626-bca4-a7a3-86f51f30b50f@redhat.com> Date: Fri, 24 Nov 2023 11:29:03 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] Improve performance of libc locks To: Wilco Dijkstra , Florian Weimer , Wilco Dijkstra via Libc-alpha References: <87h6lcbah7.fsf@oldenburg.str.redhat.com> From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_BODY,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/24/23 08:47, Wilco Dijkstra wrote: > Hi Florian,  > >> We already have SINGLE_THREAD_P checks around locking in several places. >> This makes the __libc_lock_lock check redudant in those cases.  I >> believe this was done deliberately because in many cases, we can also to >> skip cancellation handling at the same time. > > Yes, this is best for the most performance critical cases. However there are lots of > functions that use locks and many will improve with a single thread check at a > higher level. You're right that would add extra checks in cases that are not > performance critical. Right. > Maybe a solution would be to introduce __libc_lock_fast() or similar? That way one > can improve performance critical code easily without having to add special fast > paths. Today it would use SINGLE_THREAD_P, but it could potentially use RSEQ in > the future. I would prefer a solution like this because you can actively audit, and migrate the callers rather than adding a hidden (to the developer) change in the macro. >> The rand performance issue could be addressed with a similar localized >> change.  I believe that would be far less controversial. > > I can send a patch that adds fast paths to rand() if that helps unblocking this. I think it would. Add the fast path to rand(), and a microbenchmark to show that this is good for performance on your machine, that way we don't regress this change in the future when we work on rand(). I'm amenable to not having a microbenchmark, but every time we talk about performance adding a little bit to the corpus helps ensure we don't loose track of the gains. -- Cheers, Carlos.