On Wed, 2010-04-07 at 23:46 -0400, tytso@xxxxxxx wrote: > On Wed, Apr 07, 2010 at 04:21:18PM -0700, john stultz wrote: > > Further using lockstat I was able to isolate it the contention down to > > the journal j_state_lock, and then adding some lock owner tracking, I > > was able to see that the lock owners were almost always in > > start_this_handle, and jbd2_journal_stop when we saw contention (with > > the freq breakdown being about 55% in jbd2_journal_stop and 45% in > > start_this_handle). > > Hmm.... I've taken a very close look at jbd2_journal_stop(), and I > don't think we need to take j_state_lock() at all except if we need to > call jbd2_log_start_commit(). t_outstanding_credits, > h_buffer_credits, and t_updates are all documented (and verified by > me) to be protected by the t_handle_lock spinlock. > > So I ***think*** the following might be safe. WARNING! WARNING!! No > real testing done on this patch, other than "it compiles! ship it!!". > > I'll let other people review it, and maybe you could give this a run > and see what happens with this patch? So this patch seems to match the performance and has similar perf log output to what I was getting with my hack. Very very cool! I'll continue to play with your patch and see if I can con some some folks with more interesting storage setups to do some testing as well. Any thoughts for ways to rework the state_lock in start_this_handle? (Now that its at the top of the contention logs? :) thanks so much! -john -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
