lkml.org 
[lkml]   [2003]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 2/2] Futex non-page-pinning fix
Date
In message <20030828211744.3081a058.akpm@osdl.org> you write:
> Rusty Russell <rusty@rustcorp.com.au> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.277 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site