On Fri, 2005-04-01 at 06:43 +0200, Ingo Molnar wrote: > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > Hi Ingo, > > > > I was wondering if the issue the bit_spin_lock has gone into the side > > burner? [...] > > could you send me your latest patch for the bit-spin issue? My main > issue was cleanliness, so that the patch doesnt get stuck in the -RT > tree forever.
I think that's the main problem. Without changing the design of the ext3 system, I don't think there is a clean patch. The implementation that I finally settled down with was to make the j_state and j_journal_head locks two global locks. I had to make a few modifications to some spots to avoid deadlocks, but this worked out well. The problem I was worried about was this causing too much overhead. So the ext3 buffers would have to contend with each other. I don't have any tests to see if this had too much of an impact. If you are still interested, then let me know and I'll pull it out and send it to you. I preferred this method over the other wait_on_bit, since using normal spin_locks gives priority inheritance, but to put this into the buffer head seemed too much of an overhead. Also, there was that inverted_lock crap in commit.c that also caused problems. I just used the expensive wait_queue fix, where instead of just calling schedule, I put the task on the wait queue to wake up when the lock was released, and had unlock of j_state_lock wake it up. But this is expensive since every time j_state_lock is unlocked, you need to try to wake up a task that is most likely not there. This I still need to optimize. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/