> 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. - 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/