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

[Ingo Molnar]

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