From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30231 invoked by alias); 10 Feb 2013 04:56:18 -0000 Received: (qmail 30210 invoked by uid 22791); 10 Feb 2013 04:56:16 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net) (149.20.54.216) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 10 Feb 2013 04:56:12 +0000 Received: from localhost (cpe-66-108-118-205.nyc.res.rr.com [66.108.118.205]) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 5B696586218; Sat, 9 Feb 2013 20:56:14 -0800 (PST) Date: Sun, 10 Feb 2013 04:56:00 -0000 Message-Id: <20130209.235603.1409377113964639273.davem@davemloft.net> To: carlos@redhat.com Cc: carlos@systemhalted.org, drow@false.org, joseph@codesourcery.com, schwab@linux-m68k.org, thomas_schwinge@mentor.com, kkojima@rr.iij4u.or.jp, marcus.shawcroft@linaro.org, katsuki.uwatoko@toshiba.co.jp, libc-ports@sourceware.org Subject: Re: [PATCH] Avoid unnecessary busy loop in __lll_timedlock_wait on ARM. From: David Miller In-Reply-To: <5116636F.1040003@redhat.com> References: <20130209.014909.573423212502453699.davem@davemloft.net> <5116636F.1040003@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00024.txt.bz2 From: "Carlos O'Donell" Date: Sat, 09 Feb 2013 09:55:43 -0500 > I'd seen the *other* sparc pre-v9 implementation that used 64 global > locks per-library and that seemed signal unsafe and prone to deadlocks. All of these pre-v9 things are signal unsafe and deadlock. I thought about doing the kernel atomic emulation other platforms have adopted, but frankly these cpus are so old and deprecated that they're not worth doing the work for. And by the time we'd propagate all of this infrastructure necessary to support this kind of scheme, those cpus would be even more outdated. Even debian does v9-only build on 32-bit.