[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Aug 2006 09:49:54 -0700
From: "Ulrich Drepper" <drepper@...il.com>
To: "Nick Piggin" <nickpiggin@...oo.com.au>
Cc: "Eric Dumazet" <dada1@...mosbay.com>, "Andi Kleen" <ak@...e.de>,
"Ravikiran G Thirumalai" <kiran@...lex86.org>,
"Shai Fultheim (Shai@...lex86.org)" <shai@...lex86.org>,
"pravin b shelar" <pravin.shelar@...softinc.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] NUMA futex hashing
On 8/8/06, Nick Piggin <nickpiggin@...oo.com.au> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists