lkml.org 
[lkml]   [2010]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [patch 1/6] fs: icache RCU free inodes
    On Thu, Nov 11, 2010 at 10:49 PM, Nick Piggin <npiggin@kernel.dk> wrote:
    >
    > In reality, it's likely to be well under 0.1% in any real workload, even
    > an inode intensive one. So I much prefer to err on the side of less
    > complexity, to start with. There just isn't much risk of regression
    > AFAIKS, and much more risk of becoming unmaintainable too complex.

    Well, I have to say that if we don't get this lockless path lookup
    thing merged in the next merge window (ir 38-rc1), I'm going to be
    personally very disappointed (*).

    So yes, the "initial complexity" argument is certainly acceptable to
    me. It does make me suspect something is wrong, though, because quite
    frankly, the actual accesses to the inode during the lockless walk
    should be very _very_ controlled anyway. And it's trivial to do a "is
    this inode still the same one I started with" with zero locking, by
    just checking that "dentry->d_inode" is the same after-the-fact and
    checking that the dentry is still hashed. The inode type had better
    _NOT_ change if the dentry pointer is still there.

    So even if the type or i_ops changes, none of that should matter in
    the least. Nobody should _care_. We might get two wildly different
    results, but we have a trivial way to check whether the inode was
    stable after-the-fact, and just punt if it wasn't. So it really smells
    like if this is an issue, there's something wrong going on.

    Linus

    (*) To the point where if Al and Dave cannot end up agreeing on
    something, I'll just instead end up making the executive decision to
    screw the eternal nay-saying, and just merging your series. So just a
    heads-up guys: healthy discussion is fine, but obstructionism will
    _not_ work.


    \
     
     \ /
      Last update: 2010-11-12 18:37    [W:0.030 / U:181.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site