lkml.org 
[lkml]   [2010]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/3] fs: rcu protect inode hash lookups
    On Mon, Nov 01, 2010 at 04:29:22PM +0100, Eric Dumazet wrote:
    > Le mardi 02 novembre 2010 à 00:44 +1100, Dave Chinner a écrit :
    >
    > > Perhaps you should rename that file "slab_destroy_by_rcu-tips.txt",
    > > because the current name seems unrelated to the contents. :/
    > >
    >
    > Hmm, I dont know, this doc really is about the nulls thing.

    Ok, now I understand - there's a new list type that I didn't know
    about called hlist_nulls. not surprising - it's not documented
    anywhere.

    Maybe explicitly describing what the list_null pattern іs or a
    pointer to linux/include/list_nulls.h might be appropriate, because
    I managed to read that documentation and not realise that it was
    refering to a specific type of list that was already implemented
    rather than a simple marker technique.

    > This stuff also addressed one problem I forgot to tell you about: During
    > a lookup, you might find an item that is moved to another chain by
    > another cpu, so your lookup is redirected to another chain. You can miss
    > your target.

    <groan>

    So, to go to per-chain locks as per the proposed bit-lock-on-the-
    low-bit-of-the-head-pointer infrastructure, we'll have to cross that
    with the hlist_null code that plays low-bit pointer games for
    detecting the end of the chain.

    That's just messy - another hash chain specific scalability hackup.
    My dislike of using hash tables for unbounded caches is not
    improved by this....

    > You must find a way to detect such thing to restart the lookup at
    > the beginning (of the right chain). Either you stick the chain
    > number in a new inode field (that costs extra memory), or you use
    > the 'nulls' value that can let you know if you ended your lookup
    > in the right chain.

    The chain is determined by hashing the inode number. Perhaps a
    simple enough test is to hash the last inode number on a cache miss
    and if that doesn't match the hash of the lookup key we redo the
    search. That seems to me like it will avoid needing to play games
    with termination markers - does that sound reasonable?

    Cheers,

    Dave.
    --
    Dave Chinner
    david@fromorbit.com
    --
    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/

    \
     
     \ /
      Last update: 2010-11-02 01:05    [W:5.781 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site