Hello,
I've attached the output from "sh scripts/ver_linux" per the bug
reporting guidelines, and a diff of the file fs/jbd/transaction.c.
At this point, I'm trying to hunt down why some system threads, which
are executing the Lustre file system code, are taking an unexpectedly
long time executing various ext3 file system functions. I added some
debug code to these system threads in order to find out where they are
spending their time in the hopes that I can identify a place where they
may be experiencing unexpected delays.
This debugging lead me to look at the code in start_this_handle(),
contained in file fs/jbd/transaction.c, and I have a question concerning
the wake_up() logic for the thread which may go to sleep on
<j_wait_transaction_locked>.
The thread will sleep as long as <j_barrier_count> is non-zero:
repeat:
spin_lock(&journal->j_state_lock);
...
if (journal->j_barrier_count) {
spin_unlock(&journal->j_state_lock);
wait_event(...);
goto repeat;
}
...
if (...) {
prepare_to_wait(...);
spin_unlock(&journal->j_state_lock);
schedule();
finish_wait(...);
goto repeat;
}
...
The last "if (...)" represents 2 additional conditions which can cause
the thread to go to sleep in start_this_handle(), and loop back to the
"repeat" label.
In looking at how the wake_up() occurs, there exists the following
section of code:
transaction->t_updates--;
if (!transaction->t_updates) {
wake_up(&journal->j_wait_updates);
if (journal->j_barrier_count)
wake_up(&journal->j_wait_transaction_locked);
}
It would seem to me that this wake_up() will end up being a no-op, as
the thread being woken up will go back to sleep since <j_barrier_count>
is non-zero. I'm really not familiar with the journaling code, so I was
hoping to pass on my thoughts in order to get some feedback.
What I did was change this wakeup to be unconditional, and it appears to
have had a positive impact on the delays the system threads, I've been
monitoring, have been experiencing.
The other change I made, although it shouldn't affect the non-SMP system
my kernel is running on, is to change the spin_unlock()/wait_event() to
the prepare_to_wait()/spin_unlock()/schedule()/finish_wait() sequence,
and move the wake_up() in journal_unlock_updates() from after the
spin_unlock() to just before the lock is given up...I'm thinking the
thread going to sleep needs to be put on the wait queue before the
wake_up() occurs, or it could miss this wake_up().
All in all, I'm experiencing an unexpected delay in executing some ext3
file system calls, and would like to get your thoughts as to whether the
concern I have above, with a wake_up() possibly being a no-op, could
explain these execution delays.
I appreciate your help tremendously. If you folks aren't the ones I
should be talking to, please point me in the correct direction. I took
this e-mail address from the MAINTAINERS file located in the kernel
source tree.
--
Thank you,
Duane Cloud
Systems Programmer
Network Computing Services, Inc.
Army High Performance Computing Research Center (AHPCRC)
cloud at ahpcrc.org, 612-337-3407 Desk
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ver_linux
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20060814/941c8d9e/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: transaction.diff
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20060814/941c8d9e/attachment-0001.ksh>
