Re: Shared futexes (was [PATCH] FUTEX : new PRIVATE futexes)

[Nick Piggin <nickpiggin@yahoo.com.au>]

Peter Zijlstra wrote:
> On Fri, 2007-04-06 at 23:15 +1000, Nick Piggin wrote:

>>>>or given a key:
>>>>
>>>>- lookup the page from key.shared.inode->i_mapping by key.shared.pgoff
>>>>  possibly loading the page using mapping->a_ops->readpage().
>>
>>For shared futexes, wouldn't i_mapping be worse, because you'd be
>>ping-ponging the tree_lock between processes, rather than have each
>>use their own mmap_sem?
> 
> 
> Your lockless pagecache work would solve most of that, no?

Yeah it would.

>>That also only helps for the wakeup case too, doesn't it? You have
>>to use the vmas to find out which inode to use to do the wait, I think?
>>(unless you introduce a new shared futex API).
> 
> 
> one could do something like this:
> 
>  struct address_space *mapping = page_mapping(page);
>  if (!mapping || mapping == &swapper_space)
>    do_private_futex();
>  else
>    do_shared_futex(mapping->host, page->index, addr % PAGE_SIZE);
> 
> 
> But alas, it seems I overlooked that the mmap_sem also protects the page
> tables as pointed out by Hugh, so this is all in fain it seems.
> 
> A well.

Well if it turned out to be a real problem, we _could_ introduce a new
futex API that takes a file descriptor+offset.

The old futex API is basically just a shorthand for choosing between
shared and private, depending on what the vma at the given address
happens to be.

-- 
SUSE Labs, Novell Inc.