Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks

[Steven Rostedt]

On Thu, 17 Mar 2005, Lee Revell wrote:

>
> Sorry, it's hard to follow this thread.  Just to make sure we're all on
> the same page, what exactly is the symptom of this ext3 issue you are
> working on?  Is it a performance regression, or a latency issue, or a
> lockup - ?
>
> Whatever your problem is, I am not seeing it.
>

The root is a lockup.  I think you can get this lockup whether or not it
is PREEMPT_RT or PREEPMT_DESKTOP.  All you need is CONFIG_PREEMPT turned
on. Then this is what you want to do on a UP Machine.

Set kjournald to FIFO (any realtime priority).  And then from a non-RT
task, just do a "make clean; make" on the kernel. It may take a few
minutes but your system will lock up.  That's because kjournal will wait
on the bit_spin_lock, but will never be preempted by the one holding the
lock, because it is FIFO and the one holding the lock (the kernel compile)
is not RT. Even if it was, and the same priority as kjournal, it would
still lock, since kjournal is FIFO and will only yield to higher
priority threads.

Now this lockup has uncovered other problems with ext3.  Mainly that it
uses bit spinlocks, which in of itself is bad.  You don't want a busy wait
unless you really need it.  A normal spinlock is such a thing in vanilla
SMP systems, since a schedule would take longer than the one holding the
lock. Ingo's RT kernel, removes most of these, and makes them into
mutexes.  This may slow down the overall performance but it shortens
latencies for RT tasks, which is what RT tries to do.

Now the latest problem is also bad, since you should never just call
schedule as a "yield" to let someone else release a lock.  Since the
ranking order of the locks prevents just grabbing the lock and then
risking a deadlock, ext3 tries to get the lock, and if it fails, it
releases the other lock it has, calls schedule, then tries again.  This is
usually bad, since it would most likely be rescheduled, so basically it is
worst than a spinlock, since it actually goes through the schedule logic
again and spins!  With Ingo's RT patch, this also becomes a deadlock
the same way as bit_spin_locks can.

Hope this helps,

-- 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/