Messages in this thread | | | Date | Fri, 27 Sep 2002 19:01:48 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [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.
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/
| |