In article <200302112307.h1BN77F02985@parity-error.sm.sony.co.jp>,
enami tsugutomo <enami@sm.sony.co.jp> wrote:
>Hi.
>
>I sometimes sees long name hash chain like this:
>
>enami@prot-fault% more vmstat.out 
>		    total     used     util	 num  average  maximum
>hash table	  buckets  buckets	  %    items	chain	 chain
>nchash		   131072    47243    36.04    72000	 1.52	  1071
>
>There is 2 scenario:
>
>1) cache_lookup() returns -1 if failed to lock vnode or find v_id
>   mismatch after the cache hit.  Then, vfs lookup routine may does
>   normal processing and will enter new cache entry.  Unless parent's
>   v_id changes, it will go to the same bucket.
>
>2) At least nfs_lookup() routine decides the hit cache invalid by
>   itself, and does normal processing and enter new cache entry.  For
>   the same reason above, new entry will go the same bucket.
>
>For 1), I think cache_lookup() should remove the entry if it returns
>-1.

Do you mean remove the entry if v_id is not found, and keep the entry
if the vnode cannot be locked?

>
>For 2), I can imagine two fix.  one is to introduce new function to
>remove cache entry and call it where appropriate in addition to
>cache_purge().  The other is to lookup an existing entry in
>cache_enter() and reuse it if there is.  I prefer the latter.

I think I prefer the latter too.

christos