All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] jbd2: Optimize jbd2_log_do_checkpoint() a bit
Date: Wed, 3 Sep 2014 18:03:26 +0200	[thread overview]
Message-ID: <20140903160326.GB17066@quack.suse.cz> (raw)
In-Reply-To: <20140902215930.GJ6232@thunk.org>

On Tue 02-09-14 17:59:30, Ted Tso wrote:
> On Tue, Sep 02, 2014 at 07:18:30PM +0200, Jan Kara wrote:
> > When we discover written out buffer in transaction checkpoint list we
> > don't have to recheck validity of a transaction. Either this is the last
> > buffer in a transaction - and then we are done - or this isn't and then
> > we can just take another buffer from the checkpoint list without
> > dropping j_list_lock.
> > 
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > ---
> >  fs/jbd2/checkpoint.c | 13 ++++++++-----
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
> > index 993a187527f3..3722e2e53638 100644
> > --- a/fs/jbd2/checkpoint.c
> > +++ b/fs/jbd2/checkpoint.c
> > @@ -343,12 +343,15 @@ restart:
> >  		if (!buffer_dirty(bh)) {
> >  			if (unlikely(buffer_write_io_error(bh)) && !result)
> >  				result = -EIO;
> > -			get_bh(bh);
> >  			BUFFER_TRACE(bh, "remove from checkpoint");
> > -			__jbd2_journal_remove_checkpoint(jh);
> > -			spin_unlock(&journal->j_list_lock);
> > -			__brelse(bh);
> 
> Currently, all of the places which call
> __jbd2_jouranl_remove_checkpoint(jh) are doing so with an elevated
> b_count.  For example, see __try_to_free_cp_buf().
  I did a bit of archeology and commit
932bb305ba2a01cd62809644d569f004e77a4355 removed the need to hold buffer
reference when calling __jbd2_journal_remove_checkpoint(). So it should be
safe to remove that reference handling also from __try_to_free_cp_buf().

> After doing a lot of desk checking, I can't see any reason for holding
> the elevanted b_count, so I think it should be to remove it, but then
> we can simplify the other uses __try_to_free_cp_buf().  For example,
> in the loop that I folded from __wait_cp_io, we could drop the done
> variable and change:
> 
> 		done = __jbd2_journal_remove_checkpoint(jh);
> 		__brelse(bh);
> 
> to this:
> 
> 		__brelse(bh);
> 		if (__jbd2_journal_remove_checkpoint(jh))
> 			break;
  Well, we don't even need to grab bh reference unless we find the buffer
is locked and are going to wait for it. And yes, we can get rid of that
'done' variable.

> How much testing have you done of this optimization?  I'm tempted to
> try nuking all of the elevated b_counts around the call to
> __jbd2_journal_remove_checkpoint(), and then doing a test to see if
> anything blows up.
  Honestly, I didn't test much but I'm pretty confident we are safe to
remove those bh refs ;)

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  parent reply	other threads:[~2014-09-03 16:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-02 17:18 [PATCH] jbd2: Optimize jbd2_log_do_checkpoint() a bit Jan Kara
2014-09-02 21:59 ` Theodore Ts'o
2014-09-02 22:46   ` [PATCH 1/2] jbd2: don't call get_bh() before calling __jbd2_journal_remove_checkpoint() Theodore Ts'o
2014-09-02 22:46     ` [PATCH 2/2] jbd2: optimize jbd2_log_do_checkpoint() a bit Theodore Ts'o
2014-09-03  7:54     ` [PATCH 1/2] jbd2: don't call get_bh() before calling __jbd2_journal_remove_checkpoint() Yuanhan Liu
2014-09-03 16:08     ` Jan Kara
2014-09-03 18:38       ` [PATCH -v2] " Theodore Ts'o
     [not found]     ` <CAGZGoEfjAZuOAbp-AqA-kiL2aTwiRXDO_Di=LPDovRBDNSn5dw@mail.gmail.com>
2014-09-03 17:30       ` [PATCH 1/2] " Theodore Ts'o
2014-09-03 16:03   ` Jan Kara [this message]
2014-10-10 14:23 [PATCH 0/2 v2] Fix data corruption when blocksize < pagesize for mmapped data Jan Kara
2014-10-10 14:23 ` [PATCH] jbd2: Optimize jbd2_log_do_checkpoint() a bit Jan Kara
2014-10-10 14:23   ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140903160326.GB17066@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.