Date: Tue, 26 Aug 2003 00:02:18 -0700
From: Andrew Morton <akpm@osdl.org>
To: Ingo Molnar <mingo@redhat.com>
Cc: rusty@rustcorp.com.au, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] Futex non-page-pinning fix
Message-Id: <20030826000218.2ceaea1d.akpm@osdl.org>
In-Reply-To: <Pine.LNX.4.44.0308260233550.20822-100000@devserv.devel.redhat.com>
References: <20030825231449.7de28ba6.akpm@osdl.org>
	<Pine.LNX.4.44.0308260233550.20822-100000@devserv.devel.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1279
Lines: 29

Ingo Molnar <mingo@redhat.com> wrote:
>
>  > What about the option of not pinning the pages at all: just fault
>  > them in when required?
> 
>  precisely what scheme do you mean by this? There are two important points:  
>  when a thread sleeps on a futex, and when some thread does a wakeup on a
>  futex address. We cannot hash the futex based on the virtual address
>  (arbitrary share-ability of futex pages is another key appeal of them),
>  and if by the time the wakeup happens the physical page goes away how do
>  we find which threads are queued on this address?

I was suggesting that we hash the futex on mm+vaddr.  Yes, differing vaddrs
break that.

umm, how about hashing only on offset into page?  That reduces the number of
threads which need to be visited in futex_wake() by a factor of up to 1024.

In futext_wake(), fault in and pin the page, then for each thread which is
waiting on a futex which has the same offset into a page, do a
get_user_pages+follow_page, see if he's waiting on the just-faulted-in
page?


-
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/