All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org, jack@suse.cz, lherbolt@redhat.com
Subject: Re: [PATCH 2/2] xfs: rework datasync tracking and execution
Date: Fri, 19 Sep 2025 08:30:39 -0700	[thread overview]
Message-ID: <aM13H6P-lMYjR-9k@infradead.org> (raw)
In-Reply-To: <20250917222446.1329304-3-david@fromorbit.com>

On Thu, Sep 18, 2025 at 08:12:54AM +1000, Dave Chinner wrote:
> Jan demostrated that reducing the ifdatasync lock hold time can

s/demostrated/demonstrated/

> came to the conclusion that seperately tracking datasync flush

s/seperately/separately/

> seqeunces was the best approach to solving the problem.
 
s/seqeunces/sequences/g

> operations are allo done under ILOCK_EXCL context:

s/allo/all/

>  xfs_fsync_flush_log(
>  	struct xfs_inode	*ip,
>  	bool			datasync,
>  	int			*log_flushed)
>  {
> +	struct xfs_inode_log_item *iip = ip->i_itemp;
> +	xfs_csn_t		seq = 0;
>  
> +	spin_lock(&iip->ili_lock);
> +	if (datasync)
> +		seq = iip->ili_datasync_seq;
> +	else
> +		seq = iip->ili_commit_seq;
> +	spin_unlock(&iip->ili_lock);

If we care about the additional speedup of the READ_ONCE done
in Jan's patch we could make that configurable on CONFIG_64BIT
here.  There's precedence for that in i_size_read for that in the
VFS.  If we have a helper like:

static inline bool
xfs_inode_sync_csn(
	struct xfs_inode	*ip,
 	bool			datasync,
	xfs_csn_t		*seq)
 {
	struct xfs_inode_log_item *iip = ip->i_itemp;

	if (!iip)
		return false;

	spin_lock(&iip->ili_lock);
	if (datasync)
		*seq = iip->ili_datasync_seq;
	else
		*seq = iip->ili_commit_seq;
	spin_unlock(&iip->ili_lock);
	return true;
}

we could isolate that to one single place as well.

But even without that, the patch looks fine:

Reviewed-by: Christoph Hellwig <hch@lst.de>

  reply	other threads:[~2025-09-19 15:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-17 22:12 [PATCH 0/2] xfs: reduce ILOCK contention on O_DSYNC DIO Dave Chinner
2025-09-17 22:12 ` [PATCH 1/2] xfs: rearrange code in xfs_inode_item_precommit Dave Chinner
2025-09-18 22:49   ` Darrick J. Wong
2025-09-19 15:19   ` Christoph Hellwig
2025-09-19 16:08     ` Darrick J. Wong
2025-09-22 18:12       ` Christoph Hellwig
2025-09-17 22:12 ` [PATCH 2/2] xfs: rework datasync tracking and execution Dave Chinner
2025-09-19 15:30   ` Christoph Hellwig [this message]
2025-09-23 12:12     ` Carlos Maiolino
2025-09-23 13:51 ` [PATCH 0/2] xfs: reduce ILOCK contention on O_DSYNC DIO Carlos Maiolino

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=aM13H6P-lMYjR-9k@infradead.org \
    --to=hch@infradead.org \
    --cc=david@fromorbit.com \
    --cc=jack@suse.cz \
    --cc=lherbolt@redhat.com \
    --cc=linux-xfs@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.