[lkml]   [2004]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: dentry bloat.
    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.025 / U:6.452 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site