From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20529 invoked by alias); 28 Mar 2014 18:25:08 -0000 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 Received: (qmail 20503 invoked by uid 89); 28 Mar 2014 18:25:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Mar 2014 18:25:06 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2SIP2g7017873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 14:25:02 -0400 Received: from [10.36.4.41] (vpn1-4-41.ams2.redhat.com [10.36.4.41]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2SIOx3l005026; Fri, 28 Mar 2014 14:24:59 -0400 Subject: Re: [PATCH] Fix __lll_timedlock_wait busy-wait issue From: Torvald Riegel To: "Joseph S. Myers" Cc: Will Newton , Maxim Kuvyrkov , bniebuhr@efjohnson.com, uclibc@uclibc.org, "libc-ports@sourceware.org" , libc-alpha In-Reply-To: References: <1395409800-4457-1-git-send-email-bniebuhr@efjohnson.com> <09F962CB-595F-4FAB-9435-52C237DB402C@linaro.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 28 Mar 2014 18:25:00 -0000 Message-ID: <1396031098.19076.3792.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00005.txt.bz2 On Thu, 2014-03-27 at 22:01 +0000, Joseph S. Myers wrote: > I don't know how this might relate to > (see > and > and the rest > of that thread). But my preference for how to address this is definitely > to move to unifying lowlevellock.[ch] files across as many architectures > as possible - which requires someone to understand the differences and > produce a careful analysis that shows what the best form for generic files > is and what cases actually require architecture-specific files to override > those generic files (preferably overriding only the bits that need > overriding). > I agree. My gut feeling is that the locks should eventually become unified C code, using atomics to do the synchronization; architecture-specific code should be either in the atomics or in more generally useful spin-waiting code (which could be used by other sync constructs as well). The futex syscall is really on the slowpath; if you hit it, you will have had at least a cache miss on the futex var, and doing the syscall will likely give you more cache misses. Therefore, I don't see a reason why the futex syscall needs to have custom asm implementations such as on x86 currently.