Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07

[Steven Rostedt]

On Fri, 2005-04-01 at 06:43 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/