From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114212 invoked by alias); 15 Jan 2019 09:32:53 -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 114203 invoked by uid 89); 15 Jan 2019 09:32:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=health, torvald, Riegel, Torvald X-HELO: mx1.redhat.com From: Florian Weimer To: Torvald Riegel Cc: Carlos O'Donell , "H.J. Lu" , Szabolcs Nagy , libc-alpha Subject: Re: [PATCH] NUMA spinlock [BZ #23962] References: <20181226025019.38752-1-ling.ma@MacBook-Pro-8.local> <7D8A82D6-6F0A-4860-856A-EB0C8CD13E9C@antfin.com> <0a474516-b8c8-48cf-aeea-e57c77b78cbd.ling.ml@antfin.com> <8c67f319-31bf-818b-4a89-66d25328026e@arm.com> <87ef9oe0zf.fsf@oldenburg2.str.redhat.com> <97275e72-dc1b-fc2a-d908-b94ef7064ed8@redhat.com> <87y37siic1.fsf@oldenburg2.str.redhat.com> <479415e1-3aba-b456-fc67-0614fbd462a1@redhat.com> <3ff867626ab263d456591509f57de0dc2ef99118.camel@redhat.com> Date: Tue, 15 Jan 2019 09:32:00 -0000 In-Reply-To: <3ff867626ab263d456591509f57de0dc2ef99118.camel@redhat.com> (Torvald Riegel's message of "Mon, 14 Jan 2019 23:45:06 +0100") Message-ID: <87ef9e6zb4.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-01/txt/msg00325.txt.bz2 * Torvald Riegel: > On Thu, 2019-01-10 at 11:41 -0500, Carlos O'Donell wrote: >> On 1/10/19 11:32 AM, Florian Weimer wrote: >> > * Carlos O'Donell: >> > >> > > My opinion is that for the health and evolution of a NUMA-aware spinlock >> > > and MCS lock, that we should create a distinct project and library that >> > > should have those locks, and then work to put them into downstream >> > > distributions. This will support key users being able to use supported >> > > versions of those libraries, and give the needed feedback about the API >> > > and the performance. It may take 1-2 years to get that feedback and every >> > > piece of feedback will improve the final API/ABI we put into glibc or >> > > even into the next ISO C standard as pat of the C thread interface. >> > >> > I think it's something taht could land in tbb, for which many >> > distributions already have mechanisms to ship updated versions after a >> > release. >> >> Absolutely. That's a great idea. >> > > I don't think tbb is a useful vehicle. It would require that many > applications use the tbb mutexes, which I doubt is the case. That doesn't really matter because it's a new API anyway. Thanks, Florian