[lkml]   [2002]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] 'virtual => physical page mapping cache', vcache-2.5.38-B8

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:29    [W:0.303 / U:0.828 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site