lkml.org 
[lkml]   [2005]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
    From
    Date
    On Fri, 2005-08-12 at 14:58 +0200, Ingo Molnar wrote:
    > FYI, in -53-05 i've added a bh->b_update_lock, which enabled me to get
    > rid of the bitlock ugliness in fs/buffer.c. Maybe it could be used to
    > have a better fix for the jbd bitlock thing too?

    Well, I just spent several hours trying to use the b_update_lock in
    implementing something to replace the bit spinlocks for RT. It's
    getting really ugly and I just hit a stone wall.

    The problem is that I have two locks to work with. A
    jbd_lock_bh_journal_head and a jbd_lock_bh_state. Unfortunately, I also
    have a ranking order of:

    jbd_lock_bh_state -> j_state_lock -> jbd_lock_bh_journal_head

    If the ranking wasn't like this, I could probably make a little more
    progress.

    The jbd_lock_bh_journal_head is used to protect against creating a
    journal_head and adding it to a buffer_head. This was the obvious
    choice to use your b_update_lock as a replacement, since I need to have
    a lock before I acquired a journal descriptor.

    The jbd_lock_bh_state was going to exist in the journal desciptor that
    is stored in the buffer_head private data. But this lead to a problem
    when this is deleted. The private data is freed while the lock is held.
    So, keeping the lock in with the journal descriptor had the problem of
    being freed before it was unlocked.

    I started adding code to delay the freeing of the descriptor until after
    the lock was held, but this added another problem. There might be
    another process waiting on this lock, and when it gets it, it tests if
    the buffer_head even has a journal_descriptor for it. So, even if I
    delayed the freeing, another process could be waiting on this so you
    still may have a premature free. Not to mention that this code was
    becoming _very_ intrusive, since the freeing takes place deep inside
    functions that acquire the lock.

    So this lock has the same problem as the jbd_lock_bh_journal_head, where
    as, you have a buffer_head and you want to take this lock before you
    know that this buffer_head even has a journal descriptor attached to it.

    So, the only other solutions that I can think of is:

    a) add yet another (bloat) lock to the buffer head.

    b) Still use your b_update_lock for the jbd_lock_bh_journal_head and
    change the jbd_lock_bh_state to what I discussed earlier, and that being
    the hash wait_on_bit code.

    So do you have any ideas?

    -- Steve


    -
    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: 2005-08-26 06:31    [W:0.021 / U:122.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site