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
next prev parent 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).