[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181011111223.GD9467@quack2.suse.cz>
Date: Thu, 11 Oct 2018 13:12:23 +0200
From: Jan Kara <jack@...e.cz>
To: "Theodore Y. Ts'o" <tytso@....edu>
Cc: Adrian Hunter <adrian.hunter@...el.com>,
Andreas Dilger <adilger.kernel@...ger.ca>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: jbd2_clear_buffer_revoked_flags() takes a long time
On Wed 10-10-18 13:49:34, Theodore Y. Ts'o wrote:
> 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?
Agreed. Something like attached patch (compile-tested only)?
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
View attachment "0001-jbd2-Avoid-long-hold-times-of-j_state_lock-while-com.patch" of type "text/x-patch" (2287 bytes)
Powered by blists - more mailing lists