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