Messages in this thread | | | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01 | From | Steven Rostedt <> | Date | Fri, 26 Aug 2005 00:24:09 -0400 |
| |
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/
| |