From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15579 invoked by alias); 10 Jan 2019 19:24:33 -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 15391 invoked by uid 89); 10 Jan 2019 19:24:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=spoken, health, him X-HELO: mail-qt1-f196.google.com Return-Path: Subject: Re: [PATCH] NUMA spinlock [BZ #23962] To: Szabolcs Nagy , Florian Weimer , kemi Cc: nd , "H.J. Lu" , libc-alpha 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> <60bfc7d4-aa76-e5bf-1d1a-fd702d579128@arm.com> From: Carlos O'Donell Openpgp: preference=signencrypt Message-ID: <999d5a20-288d-ab46-954f-b13e331ca317@redhat.com> Date: Thu, 10 Jan 2019 19:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <60bfc7d4-aa76-e5bf-1d1a-fd702d579128@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-01/txt/msg00234.txt.bz2 On 1/10/19 12:52 PM, Szabolcs Nagy wrote: > On 10/01/2019 16:41, 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. >> > > in principle the pthread_spin_lock api can use this algorithm > assuming we can keep the pthread_spinlock_t abi and keep the > POSIX semantics. (presumably users ran into issues with the > existing posix api.. or how did this come up in the first place?) Correct, but meeting the ABI contract of the pthread_spinlck_t turns out to be hard, there isn't much space. I've spoken with Kemi Wang (Intel) about this specific issue, and he has some ideas to share, but I'll leave it for him to describe. -- Cheers, Carlos.