Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01

[Steven Rostedt <rostedt@goodmis.org>]

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/