Re: dentry bloat.

[Dipankar Sarma <dipankar@in.ibm.com>]

On Sat, May 08, 2004 at 12:27:50PM -0700, Linus Torvalds wrote:
> 
> On Sat, 8 May 2004, Linus Torvalds wrote:
> > On Sat, 8 May 2004, Andrew Morton wrote:
> > > 
> > > I think we can simply take ->d_lock a bit earlier in __d_lookup.  That will
> > > serialise against d_move(), fixing the problem which you mention, and also
> > > makes d_movecount go away.
> > 
> > If you do that, RCU basically loses most of it's meaning.
> 
> In particular, it should be safe to at least do the name hash and parent
> comparison without holding any lock (since even if they are invalidated by
> a concurrent "move()" operation, doing the comparison is safe). By the
> time those have matched, we are probably pretty safe in taking the lock,
> since the likelihood of the other checks matching should be pretty high.
> 
> And yes, removing d_movecount would be ok by then, as long as we re-test
> the parent inside d_lock (we don't need to re-test "hash", since if we
> tested the full name inside the lock, the hash had better match too ;)

There are couple of issues that need to be checked -

1. Re-doing the parent comparison and full name under ->d_lock
need to be benchmarked using dcachebench. That part of code
is extrememly performance sensitive and I remember that the
current d_movecount based solution was done after a lot of
benchmarking of various alternatives.

2. We need to check if doing ->d_compare() under ->d_lock will
result in locking hierarchy problems.

Thanks
Dipankar