[PATCH 0/3 v2] jbd2 performance improvements

[Theodore Ts'o <tytso@mit.edu>]

I've added a patch which tracks the delay between when a commit was
first requested, and when the commit thread actually starts processing
the commit.  In addition to helping to assess the effects of the "commit
as soon as possible after log_start_commit", it is also useful in
debugging problems caused by real time processes which might interfere
with the kjournald thread (since we've had one user ask a question about
this already).

There are other performance metrics that we should consider adding,
including:

*) using a per-cpu variable to track t_max_wait, so we can measure this
   performance metric without incurring a scalability penalty; we
   currently disable this unless debugging is enabled, which is
   unfortunate.
*) how many handles are getting blocked waiting for a transaction to
   finish, and not just the max wait time
*) keeping statistics of why various commits have been started (was it
   due to an explicit fsync, or due to O_SYNC, or due to the transaction
   time expiring --- and in the latter case, whether it is due to an
   expiry while the file system was idle, and hence was picked up by
   kjournald, or during the stop_this_handle processing)

But these are things we can save for another time...

        	      	     	    	     - Ted

Eric Sandeen (1):
  jbd2: don't wake kjournald unnecessarily

Theodore Ts'o (2):
  jbd2: commit as soon as possible after log_start_commit
  jbd2: track request delay statistics

 fs/jbd2/commit.c            | 13 ++++++++++++-
 fs/jbd2/journal.c           | 17 ++++++++++++++---
 fs/jbd2/transaction.c       |  7 +++++--
 include/linux/jbd2.h        |  8 ++++++++
 include/trace/events/jbd2.h |  8 ++++++--
 5 files changed, 45 insertions(+), 8 deletions(-)

-- 
1.7.12.rc0.22.gcdd159b