Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964991AbWHHQt5 (ORCPT ); Tue, 8 Aug 2006 12:49:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964994AbWHHQt5 (ORCPT ); Tue, 8 Aug 2006 12:49:57 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]:32072 "EHLO ug-out-1314.google.com") by vger.kernel.org with ESMTP id S964991AbWHHQt4 (ORCPT ); Tue, 8 Aug 2006 12:49:56 -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=ShELPypiFxK6eXLt9KR5Pns0LD4ZE2UmADjrJdNQBV85biv/MJLj8M+vPFz7gTHDYzKYKnz0fNGnd3MbbYNPks4cNVn3jSkOhc8PZqMEbNTql9FrWhty6W0dzumH20cuBfFXO4dtRhtBe0jwBx3lXX28UfX0+qwuUllPUKeRnFc= Message-ID: Date: Tue, 8 Aug 2006 09:49:54 -0700 From: "Ulrich Drepper" To: "Nick Piggin" Subject: Re: [RFC] NUMA futex hashing Cc: "Eric Dumazet" , "Andi Kleen" , "Ravikiran G Thirumalai" , "Shai Fultheim (Shai@scalex86.org)" , "pravin b shelar" , linux-kernel@vger.kernel.org In-Reply-To: <44D8BA39.5020405@yahoo.com.au> 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> <200608081429.44497.dada1@cosmosbay.com> <200608081447.42587.ak@suse.de> <200608081457.11430.dada1@cosmosbay.com> <44D8A9BE.3050607@yahoo.com.au> <44D8BA39.5020405@yahoo.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1247 Lines: 28 On 8/8/06, Nick Piggin wrote: > I thought mremap (no, that's already kind of messed up); or > even just getting consistency in failures (eg. so you don't have > the situation that a futex op can succeed on a previously > unmapped region). > > If you're not worried about the latter, then it might work... I'm not the least bit worried about this. It's 100% an application's fault. You cannot touch an address space if it's used, e.g., for mutexes. > I didn't initially click that the private futex API operates > purely on tokens rather than virtual memory... I haven't looked at the code in some time but I thought this got clarified in the comments. For waiting on private mutexes we need nothing but the address value itself. There is the FUTEX_WAKE_OP operation which will also write to memory but this is only the waker side and if the memory mapping is gone, just flag an error. It's another program error which shouldn't in any way slow down normal operations. - 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/