linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: jbd2_clear_buffer_revoked_flags() takes a long time
Date: Wed, 10 Oct 2018 13:49:34 -0400	[thread overview]
Message-ID: <20181010174934.GA19601@thunk.org> (raw)
In-Reply-To: <d2e1ec1a-0d7d-1acb-6887-c55ac30e4a3a@intel.com>

On Wed, Oct 10, 2018 at 04:43:27PM +0300, Adrian Hunter wrote:
> Hi
> 
> I have a case on a v4.14 kernel where the EXT4 journal commit disables
> preemption for 30ms due to jbd2_clear_buffer_revoked_flags().  That in turn
> disables preemption on other CPUs as they come to spin waiting for the same
> lock.  The side-effect of that is that it periodically blocks high priority
> tasks from running.
> 
> I see jbd2_clear_buffer_revoked_flags() iterating 32768 times calling
> __find_get_block().
> 
> Is there any way to make jbd2_clear_buffer_revoked_flags() take less time,
> or move its work out from under write_lock(&journal->j_state_lock)?

Hmm.... I'd have to look a bit more carefully and then run some tests,
but I *think* we can drop the j_state_lock at the beginning of JBD2
commit phase 1, and then grab it again right before we set
commit_transaction->t_state to T_FLUSH.

That should be safe because while the transaction state is T_LOCKED,
we can't start any new handles, so there can't be any new blocks added
to the revoke table.

Can you give that a try and see whether that solves your priority
inversion problem?

Cheers,

						- Ted

  reply	other threads:[~2018-10-11  1:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 13:43 jbd2_clear_buffer_revoked_flags() takes a long time Adrian Hunter
2018-10-10 17:49 ` Theodore Y. Ts'o [this message]
2018-10-11 11:12   ` Jan Kara
2018-10-11 12:38     ` Adrian Hunter
2018-10-16  8:49       ` Adrian Hunter
2018-10-16  9:50         ` 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=20181010174934.GA19601@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=adrian.hunter@intel.com \
    --cc=linux-ext4@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).