From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11232 invoked by alias); 3 Nov 2016 02:52:57 -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 11213 invoked by uid 89); 3 Nov 2016 02:52:56 -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=H*Ad:U*davem, H*MI:sk:1478125, chip X-HELO: shards.monkeyblade.net Date: Thu, 03 Nov 2016 02:52:00 -0000 Message-Id: <20161102.225245.471656475226254205.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: <1478125983.7146.733.camel@localhost.localdomain> References: <1478081121.7146.673.camel@localhost.localdomain> <20161102.113238.241484722789762790.davem@davemloft.net> <1478125983.7146.733.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00096.txt.bz2 From: Torvald Riegel Date: Wed, 02 Nov 2016 23:33:03 +0100 > On Wed, 2016-11-02 at 11:32 -0400, David Miller wrote: >> From: Torvald Riegel >> > Or do you intend to write sparc-specific versions of all the concurrent >> > data structures that are process-shared? >> >> This would be necessary anyways, if we have two modes. One that does >> the pure-userland code path and one that does the kernel helper code >> path. > > All the other archs that use a kernel helper for CAS don't need it. If > you can call the helper in the atomic operations, you won't need a new > algorithm except if you wanted to optimize the generic one. > >> Furthermore, sparc specific versions are needed in any case since we >> have the v9 detection even in the v8 libraries. Look at all of the >> code that checks for v9 in the dl_hwcap mask when deciding which >> atomic operation to use. > > Or are you talking about the implementation of the atomic operations? Just as the "are we running on a v9 chip" test is a run-time one, whether we are running on a kernel with kernel CAS simulation support will be run time code path check as well. This is why we'll need sparc specific versions of the primitives, and why it would have been the more optimal if the primitives were abstracted to the point where we didn't have to duplicate so much stuff privately just to pull this off.