public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu, saukad@google.com,
	harshads@google.com
Subject: Re: [PATCH v6 02/10] ext4: for committing inode, make ext4_fc_track_inode wait
Date: Fri, 21 Jun 2024 18:33:13 +0200	[thread overview]
Message-ID: <20240621163313.equbxelyeetrxb6w@quack3> (raw)
In-Reply-To: <20240529012003.4006535-3-harshadshirwadkar@gmail.com>

On Wed 29-05-24 01:19:55, Harshad Shirwadkar wrote:
> If the inode that's being requested to track using ext4_fc_track_inode
> is being committed, then wait until the inode finishes the
> commit. Also, add calls to ext4_fc_track_inode at the right places.
> 
> With this patch, now calling ext4_reserve_inode_write() results in
> inode being tracked for next fast commit. A subtle lock ordering
> requirement with i_data_sem (which is documented in the code) requires
> that ext4_fc_track_inode() be called before grabbing i_data_sem. So,
> this patch also adds explicit ext4_fc_track_inode() calls in places
> where i_data_sem grabbed.
> 
> Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
> ---
>  fs/ext4/fast_commit.c | 34 ++++++++++++++++++++++++++++++++++
>  fs/ext4/inline.c      |  3 +++
>  fs/ext4/inode.c       |  4 ++++
>  3 files changed, 41 insertions(+)
> 
> diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
> index a1aadebfcd66..fa93ce399440 100644
> --- a/fs/ext4/fast_commit.c
> +++ b/fs/ext4/fast_commit.c
> @@ -581,6 +581,8 @@ static int __track_inode(struct inode *inode, void *arg, bool update)
>  
>  void ext4_fc_track_inode(handle_t *handle, struct inode *inode)
>  {
> +	struct ext4_inode_info *ei = EXT4_I(inode);
> +	wait_queue_head_t *wq;
>  	int ret;
>  
>  	if (S_ISDIR(inode->i_mode))
> @@ -598,6 +600,38 @@ void ext4_fc_track_inode(handle_t *handle, struct inode *inode)
>  	if (ext4_test_mount_flag(inode->i_sb, EXT4_MF_FC_INELIGIBLE))
>  		return;
>  
> +	if (!test_opt2(inode->i_sb, JOURNAL_FAST_COMMIT) ||
> +	    (EXT4_SB(inode->i_sb)->s_mount_state & EXT4_FC_REPLAY) ||
> +		ext4_test_mount_flag(inode->i_sb, EXT4_MF_FC_INELIGIBLE) ||
> +		!list_empty(&ei->i_fc_list))

Indentation here is wrong (we never indent conditions by the same amount as
subsequent code block). Also EXT4_MF_FC_INELIGIBLE was just tested above so
why repeat it and ext4_fc_disabled() tested the EXT4_FC_REPLAY and
JOURNAL_FAST_COMMIT flags. So list_empty() should be the only thing needed
here.

BTW a separate helper for ext4_fc_disabled() + EXT4_MF_FC_INELIGIBLE test
would be a nice cleanup as it is a pattern happening in quite a few places.

> +		return;
> +
> +	/*
> +	 * If we come here, we may sleep while waiting for the inode to
> +	 * commit. We shouldn't be holding i_data_sem in write mode when we go
> +	 * to sleep since the commit path needs to grab the lock while
> +	 * committing the inode.
> +	 */
> +	WARN_ON(lockdep_is_held_type(&ei->i_data_sem, 1));

Actually even holding it in read mode is problematic. rwsems can block
other readers from acquiring rwsem if there's some writer waiting to
acquire the lock (and that will be blocked behind us). Shortly, this should
be just lockdep_is_held().

Otherwise the patch looks good.

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

  reply	other threads:[~2024-06-21 18:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-29  1:19 [PATCH v6 00/10] Ext4 fast commit performance patch series Harshad Shirwadkar
2024-05-29  1:19 ` [PATCH v6 01/10] ext4: convert i_fc_lock to spinlock Harshad Shirwadkar
2024-06-21 16:19   ` Jan Kara
2024-05-29  1:19 ` [PATCH v6 02/10] ext4: for committing inode, make ext4_fc_track_inode wait Harshad Shirwadkar
2024-06-21 16:33   ` Jan Kara [this message]
2024-06-28 14:45   ` Jan Kara
2024-07-01 22:08   ` Theodore Ts'o
2024-07-12 17:09     ` harshad shirwadkar
2024-05-29  1:19 ` [PATCH v6 03/10] ext4: mark inode dirty before grabbing i_data_sem in ext4_setattr Harshad Shirwadkar
2024-06-28 13:15   ` Jan Kara
2024-05-29  1:19 ` [PATCH v6 04/10] ext4: rework fast commit commit path Harshad Shirwadkar
2024-06-28 13:43   ` Jan Kara
2024-07-13  1:38     ` harshad shirwadkar
2024-07-17 12:11       ` Jan Kara
2024-05-29  1:19 ` [PATCH v6 05/10] ext4: drop i_fc_updates from inode fc info Harshad Shirwadkar
2024-05-29  1:19 ` [PATCH v6 06/10] ext4: update code documentation Harshad Shirwadkar
2024-05-29  1:20 ` [PATCH v6 07/10] ext4: add nolock mode to ext4_map_blocks() Harshad Shirwadkar
2024-06-28 14:18   ` Jan Kara
2024-07-13  2:01     ` harshad shirwadkar
2024-07-17 13:07       ` Jan Kara
2024-05-29  1:20 ` [PATCH v6 08/10] ext4: introduce selective flushing in fast commit Harshad Shirwadkar
2024-06-28 14:33   ` Jan Kara
2024-05-29  1:20 ` [PATCH v6 09/10] ext4: temporarily elevate commit thread priority Harshad Shirwadkar
2024-06-28 14:42   ` Jan Kara
2024-05-29  1:20 ` [PATCH v6 10/10] ext4: make fast commit ineligible on ext4_reserve_inode_write failure Harshad Shirwadkar
2024-06-28 14:47   ` 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=20240621163313.equbxelyeetrxb6w@quack3 \
    --to=jack@suse.cz \
    --cc=harshads@google.com \
    --cc=harshadshirwadkar@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=saukad@google.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox