From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35218 invoked by alias); 1 Nov 2016 16:51:30 -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 35205 invoked by uid 89); 1 Nov 2016 16:51:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=invisible, decades X-HELO: shards.monkeyblade.net Date: Tue, 01 Nov 2016 16:51:00 -0000 Message-Id: <20161101.125117.2228115672691137607.davem@davemloft.net> To: triegel@redhat.com Cc: andreas@gaisler.com, libc-alpha@sourceware.org, adhemerval.zanella@linaro.org, carlos@redhat.com, software@gaisler.com Subject: Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware From: David Miller In-Reply-To: <1478018801.7146.655.camel@localhost.localdomain> References: <1478015984.7146.645.camel@localhost.localdomain> <20161101.120933.844037675386229627.davem@davemloft.net> <1478018801.7146.655.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00038.txt.bz2 From: Torvald Riegel Date: Tue, 01 Nov 2016 17:46:41 +0100 > On Tue, 2016-11-01 at 12:09 -0400, David Miller wrote: >> From: Torvald Riegel >> Date: Tue, 01 Nov 2016 16:59:44 +0100 >> >> > On Tue, 2016-11-01 at 16:07 +0100, Andreas Larsson wrote: >> >> Any comments are most welcome. The spin lock based sparcv8 semaphore >> >> implementation is currently unchanged by this patchset, but I would say >> >> that that should go as well. >> > >> > Agreed. >> >> I think tossing out all of the ldstub based v8 code is not wise. >> >> I was envisioning adding code to use ldstub on v8 when CAS is not >> available in order to maintain the status quo of what worked and >> was functional before the changes which introduced this problem >> for v8 in the first place. >> >> Having that in place until the kernel-side atomics could be >> implemented, propagated, and supported in glibc would be a nice >> intermediate state compared to what we have now. > > How do you intend to make the synchronization primitives work whose > implementation requires a CAS and for which nobody has provided an > alternative implementation that does not require CAS? The pure userland version will do what has been done for decades, by using a spinlock that protects the word we want to do atomic operations upon. A hash table of spinlocks is another option. When kernel side support exists that version would do the operation entirely inside of the kernel using whatever internal synchronization primitive it deems appropriate. It should be invisible to the user.