From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16808 invoked by alias); 22 Aug 2012 23:16:36 -0000 Received: (qmail 16789 invoked by uid 22791); 22 Aug 2012 23:16:35 -0000 X-SWARE-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_PX X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Aug 2012 23:16:21 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1T4K9q-0003j2-BE from Maxim_Kuvyrkov@mentor.com ; Wed, 22 Aug 2012 16:16:18 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Aug 2012 16:16:18 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Thu, 23 Aug 2012 00:16:15 +0100 Subject: Re: [PATCH] Unify pthread_spin_[try]lock implementations. MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: Maxim Kuvyrkov In-Reply-To: <1345112457.3083.217.camel@triegel.csb> Date: Wed, 22 Aug 2012 23:16:00 -0000 CC: Roland McGrath , Andrew Haley , David Miller , "Joseph S. Myers" , Richard Sandiford , , GLIBC Devel , Chris Metcalf Content-Transfer-Encoding: quoted-printable Message-ID: <47032406-D3C9-4383-BD8E-0DC1E92E10BA@codesourcery.com> References: <65B470D2-4D01-4BA1-AEC5-A72C0006EA22@codesourcery.com> <20120711081441.73BB22C093@topped-with-meat.com> <20120711.012509.1325789838255235021.davem@davemloft.net> <4FFD3CD9.4030206@redhat.com> <84304C03-6A49-4263-9016-05486EDC0E98@codesourcery.com> <4FFD4114.9000806@redhat.com> <20120711112235.B28CA2C099@topped-with-meat.com> <7FBB4F87-9FF3-4239-818F-5A38C8094011@codesourcery.com> <20120725181300.DD1812C0B5@topped-with-meat.com> <36A2FFD8-0C98-4AB6-8C64-2EEC5CC67A63@codesourcery.com> <1345112457.3083.217.camel@triegel.csb> To: Torvald Riegel Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00156.txt.bz2 On 16/08/2012, at 10:20 PM, Torvald Riegel wrote: > On Wed, 2012-08-15 at 15:16 +1200, Maxim Kuvyrkov wrote: >> On 26/07/2012, at 6:13 AM, Roland McGrath wrote:=20 >>> /* Machine-dependent rationale about the selection of this value. */ >>> #define SPIN_LOCK_READS_BETWEEN_CMPXCHG 1000 >=20 > This looks like an arbitrary choice. It is. > I don't want to complain about > this patch (whose goal is to just unify similar code), but let me use it > as an example. > Elsewhere in the thread, you (IIRC) mentioned that the assumption is > that a CAS is 100x slower than a load. IMO, this is a flawed assumption. > First, this has more dimensions than one instruction being slower than > another one: cache architecture, what other threads are doing and where > in the cache hierarchy/graph they are, the CAS HW implementation, etc. > Second, it's not really about the slow-down for the current thread when > executing a CAS; it's about what the CAS might do in terms of caching > and the latency at which you detect a free lock on ARM, as Andrew Haley > pointed out. Third, not all machines in an architecture are similar; a > P4 cmpxchg performs much differently to a cmpxchg on a recent x86 CPU. > Fourth, there's no test for this assumption. This are good arguments. >=20 > So, we will have to make such assumptions, but how do we make sure that > they are reasonable, and remain reasonable over time? If we don't, > these will bit-rot, and performance might degrade over time (assuming > that the assumptions were initially correct, which might be hard in the > first place). Is there a plan for this yet, or discussion about this? The usual way how this kind of problem is solved in a free software project= is that the current [arbitrary] constant causes a bottleneck on some appli= cation. Then someone who cares about that application will investigate the= problem and come to the mailing list with specific measurements and specif= ic arguments why this constant should change. If those arguments are reaso= nable and general enough, then the community will accept the change. Then = the cycle will continue. In my opinion, really solving the heck out of a problem such as this one is= not worthwhile. I'm happy with the approximate solution that we arrived t= o, but I certainly encourage anyone who thinks that this is not good enough= to step up and fix it for real and forever. >=20 >>> while Teil will use -1. >=20 > Is there a plan to include a back-off component in this generic spin > lock? (-1 would spin forever, but not do back-off.) No. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics