Re: [RFC] Peeling off dcache_lock

[Rusty Russell <rusty@rustcorp.com.au>]

On Mon, 21 Jan 2002 17:40:39 +0530
Maneesh Soni <maneesh@in.ibm.com> wrote:

> Hi All,
> 
> We have been doing experiments with dcache_lock to provide some relief from it.
> Though dcache_lock is not a very hot lock in comparision to BKL but on higher
> end machines it becomes quite contentious. We would like to have feedbacks,
> comments about the approach taken and guidance on how to improve this further.

Hi Maneesh!

	Fantastic work!  A couple of questions, and a trivial patch:

 o Would DCACHE_DEFERRED_FREE be better called DCACHE_UNLINKED?  If I
   understand correctly, it's only and always set when someone has deleted
   (unhashed) the dentry.

 o Am I correct in asserting that you could change all the
   "list_empty(dentry->dhash)" tests to
   "dentry->d_vfs_flags & DCACHE_DEFERRED_FREE" tests, and hence change the
   list_del_init() to list_del() in unhash, and thus remove the d_nexthash
   field altogether?

 o d_lookup looks like it can return an DCACHE_DEFERRED_FREE dentry: this
   seems wrong: shouldn't it loop here?

 o Were you planning on changing d_count to a non-atomic?  It seems overkill
   to have it protected by the lock, but ALSO atomic for other places.
   Could be a performance loss as well.

 o Minor nitpick: unhash() in dcache.h is plainer implemented in terms of
   __unhash().

Any chance of you making it to http://linux.conf.au next month BTW?

Thanks for the cool patch!
Rusty.
-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.