Re: Vnode API change: add global vnode cache

[Chuck Silvers <chuq%chuq.com@localhost>]

On Sun, Apr 06, 2014 at 12:14:24PM +0200, J. Hannken-Illjes wrote:
> Currently all file systems have to implement their own cache of
> vnode / fs node pairs.  Most file systems use a copy and pasted
> version of ufs_ihash.
> 
> So add a global vnode cache with lookup and remove:
[...]

hi,

the principle of this is good, but I have a couple concerns about the details:

 - why use an rb tree instead of a hash table?
   other people are saying that the lock contention is the same,
   but there are two differences:
    - updating an rb tree touches a lot more memory, so the lock is held for
      longer.
    - different parts of a hash table can easily be protected by
      different locks, but that doesn't work for a tree.

 - it looks like this increases the effective size of a vnode by a net 40 bytes
   (7 pointers added, 2 removed).  it would be better to do this without using
   more memory than we do now.  is there any real reason to have a separate
   structure for this rather than just putting the fields directly in
   struct vnode?  to avoid needing fields for the "key" pointer and key length,
   each fs could supply its own comparison function.

-Chuck