public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-xfs@vger.kernel.org, Avi Kivity <avi@scylladb.com>
Subject: Re: [PATCH 3/3] xfs: try to avoid the iolock exclusive for non-aligned direct writes
Date: Mon, 11 Jan 2021 20:14:12 +0100	[thread overview]
Message-ID: <20210111191412.GA8774@lst.de> (raw)
In-Reply-To: <20210111185920.GF1091932@bfoster>

On Mon, Jan 11, 2021 at 01:59:20PM -0500, Brian Foster wrote:
> > +	/*
> > +	 * Bmap information not read in yet or no blocks allocated at all?
> > +	 */
> > +	if (!(ifp->if_flags & XFS_IFEXTENTS) || !ip->i_d.di_nblocks)
> > +		return 0;
> > +
> > +	ret = xfs_ilock_iocb(iocb, XFS_ILOCK_SHARED);
> > +	if (ret)
> > +		return ret;
> 
> It looks like this helper is only called with ILOCK_SHARED already held.

xfs_dio_write_exclusive is called with the iolock held shared, but not
the ilock.


> > +	if (iocb->ki_pos > i_size_read(inode)) {
> > +		if (iocb->ki_flags & IOCB_NOWAIT)
> >  			return -EAGAIN;
> 
> Not sure why we need this check here if we'll eventually fall into the
> serialized check. It seems safer to me to just do 'iolock =
> XFS_IOLOCK_EXCL;' here and carry on.

It seems a little pointless to first acquire the lock for that.  But
in the end this is not what the patch is about, so I'm happy to drop it
if that is preferred.

> > -	if (unaligned_io) {
> > +	if (exclusive_io) {
> 
> Hmm.. so if we hold or upgrade to ILOCK_EXCL from the start for whatever
> reason, we'd never actually check whether the I/O is "exclusive" or not.
> Then we fall into here, demote the lock and the iomap layer may very
> well end up doing subblock zeroing. I suspect if we wanted to maintain
> this logic, the exclusive I/O check should occur for any subblock_io
> regardless of how the lock is held.

True.

  reply	other threads:[~2021-01-11 19:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 16:12 improve sub-block size direct I/O concurrency Christoph Hellwig
2021-01-11 16:12 ` [PATCH 1/3] xfs: factor out a xfs_ilock_iocb helper Christoph Hellwig
2021-01-11 18:55   ` Brian Foster
2021-01-11 16:12 ` [PATCH 2/3] xfs: make xfs_file_aio_write_checks IOCB_NOWAIT-aware Christoph Hellwig
2021-01-11 18:55   ` Brian Foster
2021-01-11 16:12 ` [PATCH 3/3] xfs: try to avoid the iolock exclusive for non-aligned direct writes Christoph Hellwig
2021-01-11 18:59   ` Brian Foster
2021-01-11 19:14     ` Christoph Hellwig [this message]
2021-01-11 19:49       ` Brian Foster
2021-01-11 20:52   ` Dave Chinner
2021-01-11 20:45 ` improve sub-block size direct I/O concurrency Dave Chinner

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=20210111191412.GA8774@lst.de \
    --to=hch@lst.de \
    --cc=avi@scylladb.com \
    --cc=bfoster@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox