Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964977AbWHHQ6M (ORCPT ); Tue, 8 Aug 2006 12:58:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964994AbWHHQ6M (ORCPT ); Tue, 8 Aug 2006 12:58:12 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]:3418 "EHLO ug-out-1314.google.com") by vger.kernel.org with ESMTP id S964977AbWHHQ6M (ORCPT ); Tue, 8 Aug 2006 12:58:12 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YOjMMR2MRSIFY7vWJXTbtJbKWYprgz6mO1tN3SPmnZJpMDTRcWjY8O4aAtCa6qmrg7lhKWUWi0dHiixMSN56+7chJQZYNM5HHXyyQy/Qi+3nouUacm7oGnGuzQQfKF/vv2AQ6Yw0zdOKSbkhtY/fmlIpmHqD/ukOmaYb4q/k1tA= Message-ID: Date: Tue, 8 Aug 2006 09:58:10 -0700 From: "Ulrich Drepper" To: "Eric Dumazet" Subject: Re: [RFC] NUMA futex hashing Cc: "Nick Piggin" , "Andi Kleen" , "Ravikiran G Thirumalai" , "Shai Fultheim (Shai@scalex86.org)" , "pravin b shelar" , linux-kernel@vger.kernel.org In-Reply-To: <200608081808.34708.dada1@cosmosbay.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060808070708.GA3931@localhost.localdomain> <44D8A9BE.3050607@yahoo.com.au> <200608081808.34708.dada1@cosmosbay.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1405 Lines: 29 On 8/8/06, Eric Dumazet wrote: > So we really can... but for 'private futexes' which are the vast majority of > futexes needed by typical program (using POSIX pshared thread mutex attribute > PTHREAD_PROCESS_PRIVATE, currently not used by NPTL glibc) Nonsense. Mutexes are by default always private. They explicitly have to be marked as sharable. This happens using the pthread_mutexattr_setpshared function which takes PTHREAD_PROCESS_PRIVATE or PTHREAD_PROCESS_SHARED in the second parameter. So the former _is_ clearly used. > Of course we would need a new syscall, and to change glibc to be able to > actually use this new private_futex syscall. No, why? The kernel already does recognize private mutexes. It just checks whether the pages used to store it are private or mapped. This requires some interaction with the memory subsystem but as long as no crashes happen the data can change underneath. It's the program's fault if it does. On the waker side you would search the local futex hash table/tree first and if this doesn't yield a match, search the global table. Wakeup calls without any waiters are usually rare. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/