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 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.