From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90896 invoked by alias); 15 Jan 2019 16:44:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 90389 invoked by uid 89); 15 Jan 2019 16:44:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=extreme X-HELO: brightrain.aerifal.cx Date: Tue, 15 Jan 2019 16:44:00 -0000 From: Rich Felker To: Torvald Riegel Cc: kemi , "H.J. Lu" , Ma Ling , GNU C Library , "Lu, Hongjiu" , "ling.ma" , Wei Xiao Subject: Re: [PATCH] NUMA spinlock [BZ #23962] Message-ID: <20190115164405.GG23599@brightrain.aerifal.cx> References: <20181226025019.38752-1-ling.ma@MacBook-Pro-8.local> <20190103204338.GU23599@brightrain.aerifal.cx> <20190103212113.GV23599@brightrain.aerifal.cx> <5c2bf8859a412759aba26a21b317ea98f6ff8eaf.camel@redhat.com> <0b4620c1-a9c5-061e-9636-65d80655a6fd@intel.com> <6eaaec4d0ae349eaf31de1239f27c01dc1f5b6a8.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6eaaec4d0ae349eaf31de1239f27c01dc1f5b6a8.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker X-SW-Source: 2019-01/txt/msg00341.txt.bz2 On Tue, Jan 15, 2019 at 01:36:56PM +0100, Torvald Riegel wrote: > > But, that's not enough. When tunable is not the bottleneck, the simple busy-waiting > > algorithm of current adaptive mutex is the major negative factor which degrades mutex > > performance. > > Note that I'm not advocating for focusing on just the adaptive mutex type. > IMO, adding this type was a mistake because whether to spin or not does not > affect semantics of the mutexes. Performance hints shouldn't be done via a > mutex' type, and all mutex implementations should consider to spin at least > a little. Strongly agreed that this was a mistake. This same sentiment is why I don't like the nomenclature "NUMA spinlock". If there are semantic differences from a normal spinlock, it should be named for the semantics, not for the form of extreme performance tuning it does. If there are no semantic differences, NUMA-optimized spinlock implementation should just be a drop-in replacement for the standard spinlock API. Rich