From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com, Christoph Hellwig <hch@lst.de>, darrick.wong@oracle.com
Subject: Re: stop using ioends for direct write completions
Date: Fri, 29 Jan 2016 09:12:33 -0500 [thread overview]
Message-ID: <20160129141232.GA43184@bfoster.bfoster> (raw)
In-Reply-To: <20160128131656.GB14876@infradead.org>
On Thu, Jan 28, 2016 at 05:16:56AM -0800, Christoph Hellwig wrote:
> Any chance to get a review for this? It should really help
> with sorting out the buffered I/O COW code.
>
I haven't taken a closer look at the patch yet. I was kind of waiting
for Dave to chime in because I'm a little confused over the back and
forth nature of dio/ioend completion lately.
My understanding is that the original requirement for ioends here was to
track the state necessary in order to defer (to wq) completions that had
to allocate transactions. Eventually, the deferred buffer state was
implemented and we no longer required an ioend for that, so we removed
the ioends here:
2ba6623 xfs: don't allocate an ioend for direct I/O completions
Then just a couple months later, we merged the following to re-add the
ioend into the dio path:
d5cc2e3f xfs: DIO needs an ioend for writes
I recall reviewing that one, but looking back afaict the ioend was used
simply to enable reuse of the ioend completion code. Now we have this
patch which presumably removes much of that code to eliminate the ioend
allocation overhead.
Neither this patch nor the previous has any technical reasoning for one
approach over the other in the commit logs, so afaics this appears to be
a matter of preference. Can we get some agreement (or discussion) on
what the right interface is to transfer information to dio completion?
E.g., is this allocation overhead noticeable? Is ioend usage problematic
for other reasons (such as copy-on-write)? Going back to the previous
patch, were there explicit reasons for using ioends aside from code
reuse? Note that the subsequent commit 6dfa1b67 ("xfs: handle DIO
overwrite EOF update completion correctly") does refer to some problems
not running dio completions in the right context... Dave?
Brian
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-01-29 14:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 10:10 stop using ioends for direct write completions Christoph Hellwig
2016-01-14 10:10 ` [PATCH] xfs: don't use " Christoph Hellwig
2016-01-28 13:16 ` stop using " Christoph Hellwig
2016-01-28 20:53 ` Darrick J. Wong
2016-01-28 21:10 ` Christoph Hellwig
2016-01-28 21:58 ` Darrick J. Wong
2016-01-28 22:02 ` Christoph Hellwig
2016-01-28 22:31 ` Darrick J. Wong
2016-01-29 8:01 ` Christoph Hellwig
2016-01-29 14:12 ` Brian Foster [this message]
2016-02-01 21:54 ` Darrick J. Wong
2016-02-02 11:17 ` Christoph Hellwig
2016-02-02 15:26 ` Brian Foster
2016-02-02 11:20 ` Christoph Hellwig
2016-02-02 15:31 ` Brian Foster
2016-02-02 16:42 ` Christoph Hellwig
2016-02-03 22:22 ` 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=20160129141232.GA43184@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=xfs@oss.sgi.com \
/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