Re: [patch] 'virtual => physical page mapping cache', vcache-2.5.38-B8

Ingo Molnar (mingo@elte.hu)
Fri, 27 Sep 2002 19:01:48 +0200 (CEST)


On Fri, 27 Sep 2002, Linus Torvalds wrote:

> You may want to do something clever to avoid taking the vcache lock in
> the COW path unless there is real reason to believe that you have to,
> but as far as I can tell, you can do that by simply adding a memory
> barrier to the end of the "insert vcache entry" thing.

the COW path lookup code already avoids taking the vcache lock - unless
the hash-head is non-empty.

> Because once you do that, and you make sure that the COW thing does the
> vcache callback _after_ changing the page tables, the COW code can
>
> - do the hash (which is invariant and has no races, since it depends
> solely on the virtual address and the VM)
> - check if the hash queue is empty
> - only if the hash queue is non-empty does the COW code need to get the
> vcache lock (and obviously it needs to re-load the hash entry from the
> queue after it got the lock, but the hash is still valid)

yeah, this is the optimization i have described in the previous mail, and
which is in the patch.

> Maybe I'm missing something, but the locking really doesn't look all
> that problematic if we just do things in the obvious order..

i agree, first hashing the vcache should work. There are some details:
if we first hash the vcache then we have to set up the queue in a way for
the callback function to notice that this queue is not futex-hashed (ie.
not live) yet. Otherwise the callback function might attempt to rehash it.
This means one more branch in the callback function, not a problem.

Ingo

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