lkml.org 
[lkml]   [2007]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 00/14] Concurrent Page Cache
    From
    Date
    On Mon, 2007-01-29 at 09:20 -0800, Christoph Lameter wrote:
    > On Sun, 28 Jan 2007, Peter Zijlstra wrote:
    >
    > > With Nick leading the way to getting rid of the read side of the tree_lock,
    > > this work continues by breaking the write side of said lock.
    >
    > Could we get the read side in separately from the write side?

    Sure, apply patches 1 through 9. 10 and up are the write side.

    > I think I
    > get the read side but the write side still looks scary to me and
    > introduces new ways of locking. Ladder locking?

    Its all quite simple really; imagine locking the whole tree path
    beginning at the root node. This obviously doesn't provide concurrency
    since holing the root node locked will avoid all other operations from
    starting.

    However, as soon as you've locked a node on the next level and can
    determine that you will never need to traverse the tree path upwards
    from this point, you can drop the lock(s) on the previous level.

    In the trivial case where you will never traverse up again, this reduces
    to ladder locking.

    Perhaps it is best illustrated with a picture (forgive the ASCII art)

    A0
    B0 B1
    C0 C1 C2 C3
    D0 D1 D2 D3 D4 D5 D6 D7

    Say we need D5, which yield the path: A0, B1, C2, D5.

    Ladder locking would end up:

    lock A0
    lock B1
    unlock A0 -> a new operation can start
    lock C2
    unlock B1
    lock D5
    unlock C2
    ** we do stuff to D5
    unlock D5

    For path locking, this would end up being something like this:
    (say we can determine we'll never cross C2 back up)

    lock A0
    lock B1
    lock C2
    unlock A0 -> a new operation can start
    unlock B1
    lock D5
    ** we do stuff to D5 and walk back up to C2
    unlock C2
    unlock D5

    > > Aside from breaking MTD this version of the concurrent page cache seems
    > > rock solid on my dual core x86_64 box.
    >
    > What exactly is the MTD doing

    drivers/mtd/devices/block2mtd.c - fudges with the pagecache, haven't
    spend any time in converting that. Shouldn't be hard.

    > and how does it break?

    Doesn't compile anymore.

    (could use atomic_long_t for mapping::nr_pages I guess)

    -
    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: 2007-01-29 19:09    [W:0.039 / U:59.844 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site