Re: [PATCH 2/2] Futex non-page-pinning fix

[Rusty Russell]

In message <20030828211744.3081a058.akpm@xxxxxxxx> you write:
> Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> >
> > Well, the patch I posted adds a futex_rehash to ___add_to_page_cache,
> 
> That's a real hotpath.  Certainly we couldn't take a global lock there.

Agreed.

> Need to find a way to rehash when moving pages around only in swapcache.  I
> thought the earlier patches were structured that way?

Yes, but I'm fairly sure they were racy.  Which is enough for me to
dislike it.

Rehashing when the ->mapping changes is simple and clear.  It's fairly
easy to push it up to the callers, and then I'll figure out which ones
are adding new pages, and which ones are moving pages from one
->mapping to another (these ones we care about).  But it has to be
under the same locks (ie. rehashing and changing the mapping an atomic
operation) otherwise someone has to prove that noone can do a futex
lookup on the page with the new mapping before it's been updated in
the hash.

The other possibility is to use some lock we already have, rather than
the futex_lock, to protect that PG_futexed bit.

I'll keep working on it.  I'm learning more about the VM, at least.

Thanks,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/