From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by sourceware.org (Postfix) with ESMTPS id 20B4C3858C2C for ; Thu, 18 Nov 2021 01:17:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 20B4C3858C2C X-IronPort-AV: E=McAfee;i="6200,9189,10171"; a="234033532" X-IronPort-AV: E=Sophos;i="5.87,243,1631602800"; d="scan'208";a="234033532" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Nov 2021 17:16:41 -0800 X-IronPort-AV: E=Sophos;i="5.87,243,1631602800"; d="scan'208";a="455108539" Received: from avandeve-mobl.amr.corp.intel.com (HELO [10.255.230.250]) ([10.255.230.250]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Nov 2021 17:16:41 -0800 Message-ID: <924a80cd-202c-99e9-a2d9-1aeda2235b83@linux.intel.com> Date: Wed, 17 Nov 2021 17:16:41 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH v6 1/4] Add LLL_MUTEX_READ_LOCK [BZ #28537] Content-Language: en-US To: "H.J. Lu" , Noah Goldstein Cc: GNU C Library , Florian Weimer , Oleh Derevenko , Andreas Schwab , "Paul A . Clarke" References: <20211111162428.2286605-1-hjl.tools@gmail.com> <20211111162428.2286605-2-hjl.tools@gmail.com> From: Arjan van de Ven In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 01:17:09 -0000 On 11/17/2021 4:31 PM, H.J. Lu wrote: >> Yes, but the loop will be able to run `max_cnt` iterations much faster now. >> Just wondering if the value needs to be re-tuned. Not that is necessarily needs >> to be. > Maybe if we can find some data to show for. > wondering when this was last tuned.. I assume todays CPUs and CPUs from, say, 5 or 10 years ago have an order of magnitude different performance in this regard.... if there wasn't a need to retune during that, maybe this value is so robust that it doesn't need retuning. or maybe it's time to retune this in general sometime soon after this patch goes in ;)