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

Nick Piggin
2007-04-06T13:41:09Z

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.