From: Christoph Hellwig <hch@infradead.org>
To: Avi Kivity <avi@scylladb.com>
Cc: Brian Foster <bfoster@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Tomasz Grabiec <tgrabiec@scylladb.com>,
linux-xfs@vger.kernel.org, Goldwyn Rodrigues <rgoldwyn@suse.com>,
linux-aio@kvack.org
Subject: Re: io_submit() blocks for writes for substantial amount of time
Date: Wed, 20 Sep 2017 07:49:36 -0700 [thread overview]
Message-ID: <20170920144936.GA12638@infradead.org> (raw)
In-Reply-To: <8b7b0822-9d57-4fc9-d55f-b0f94d8a5cbd@scylladb.com>
On Wed, Sep 20, 2017 at 02:11:49PM +0300, Avi Kivity wrote:
> I think it's still preferable to avoid a workqueue and its non-deterministic
> latencies and context switches if we can prove that a particular iocb will
> not require a synchronous operation. If that can be done then 4.13 nowait
> aio also works - the user provides the workqueue equivalent. The only
> problem is if we can't prove in advance that an iocb will require blocking.
The code is generally pessimistic and bails out rather too often.
The only issue not solved is memory allocation, at the moment we could
still block on them so this will need some more work. For XFS direct
I/O the only memory allocations in that path should be the bios.
> 1. Short writes - just ignore the tail of a too-large iovec. May cause
> buggy applications to fail, so probably not a good idea.
We could still do it the same way we did RWF_NOWAIT - require an
explicit opt-in for what should be the defalt behavior because we
change the historic behavior.
> 3. Borrow the mm, and pin from the wq - I gather it was considered and
> rejected, but maybe it can be reconsidered.
It was done before in vendor kernels, and I think we also had code
for it in a driver implementing aio. I'd need to look up the whole
history as I don't remember it.
next prev parent reply other threads:[~2017-09-20 14:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-19 8:50 io_submit() blocks for writes for substantial amount of time Tomasz Grabiec
2017-09-19 12:27 ` Brian Foster
2017-09-19 14:58 ` Christoph Hellwig
2017-09-19 16:31 ` Avi Kivity
2017-09-19 17:39 ` Brian Foster
2017-09-19 20:34 ` Christoph Hellwig
2017-09-20 6:17 ` Avi Kivity
2017-09-20 10:50 ` Brian Foster
2017-09-20 11:11 ` Avi Kivity
2017-09-20 14:49 ` Christoph Hellwig [this message]
2017-09-23 18:23 ` Avi Kivity
2017-09-19 20:34 ` Christoph Hellwig
2017-09-20 6:14 ` Avi Kivity
2017-09-19 16:29 ` Avi Kivity
2017-09-19 17:38 ` Brian Foster
2017-09-19 17:53 ` Tomasz Grabiec
2017-09-19 23:38 ` 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=20170920144936.GA12638@infradead.org \
--to=hch@infradead.org \
--cc=avi@scylladb.com \
--cc=bfoster@redhat.com \
--cc=linux-aio@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=rgoldwyn@suse.com \
--cc=tgrabiec@scylladb.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;
as well as URLs for NNTP newsgroup(s).