linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeffle Xu <jefflexu@linux.alibaba.com>
To: axboe@kernel.dk, hch@infradead.org, viro@zeniv.linux.org.uk
Cc: linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
	ming.lei@redhat.com, joseph.qi@linux.alibaba.com,
	xiaoguang.wang@linux.alibaba.com
Subject: [v2 2/2] block,iomap: disable iopoll when split needed
Date: Thu, 15 Oct 2020 15:40:31 +0800	[thread overview]
Message-ID: <20201015074031.91380-3-jefflexu@linux.alibaba.com> (raw)
In-Reply-To: <20201015074031.91380-1-jefflexu@linux.alibaba.com>

Both blkdev fs and iomap-based fs (ext4, xfs, etc.) currently support
sync iopoll. One single bio can contain at most BIO_MAX_PAGES, i.e. 256
bio_vec. If the input iov_iter contains more than 256 segments, then
the IO request described by this iov_iter will be split into multiple
bios, which may cause potential deadlock for sync iopoll.

When it comes to sync iopoll, the bio is submitted without REQ_NOWAIT
flag set and the process may hang in blk_mq_get_tag() if the input
iov_iter has to be split into multiple bios and thus rapidly exhausts
the queue depth. The process has to wait for the completion of the
previously allocated requests, which should be done by the following
sync polling, and thus causing a deadlock.

Actually there's subtle difference between the behaviour of handling
HIPRI IO of blkdev and iomap, when the input iov_iter need to split
into multiple bios. blkdev will set REQ_HIPRI for only the last split
bio, leaving the previous bio queued into normal hardware queues, which
will not cause the trouble described above though. iomap will set
REQ_HIPRI for all bios split from one iov_iter, and thus may cause the
potential deadlock decribed above.

Disable iopoll when one request need to be split into multiple bios.
Though blkdev may not suffer the problem, still it may not make much
sense to iopoll for big IO, since iopoll is initially for small size,
latency sensitive IO.

Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
---
 fs/block_dev.c       | 7 +++++++
 fs/iomap/direct-io.c | 9 ++++++++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 9e84b1928b94..a8a52cab15ab 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -491,6 +491,13 @@ blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
 	if (is_sync_kiocb(iocb) && nr_pages <= BIO_MAX_PAGES)
 		return __blkdev_direct_IO_simple(iocb, iter, nr_pages);
 
+	/*
+	 * IOpoll is initially for small size, latency sensitive IO.
+	 * Disable iopoll if split needed.
+	 */
+	if (nr_pages > BIO_MAX_PAGES)
+		iocb->ki_flags &= ~IOCB_HIPRI;
+
 	return __blkdev_direct_IO(iocb, iter, min(nr_pages, BIO_MAX_PAGES));
 }
 
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index c1aafb2ab990..1628f9ff311a 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -249,10 +249,17 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
 	orig_count = iov_iter_count(dio->submit.iter);
 	iov_iter_truncate(dio->submit.iter, length);
 
-	nr_pages = iov_iter_npages(dio->submit.iter, BIO_MAX_PAGES);
+	nr_pages = iov_iter_npages(dio->submit.iter, BIO_MAX_PAGES + 1);
 	if (nr_pages <= 0) {
 		ret = nr_pages;
 		goto out;
+	} else if (nr_pages > BIO_MAX_PAGES) {
+		/*
+		 * IOpoll is initially for small size, latency sensitive IO.
+		 * Disable iopoll if split needed.
+		 */
+		nr_pages = BIO_MAX_PAGES;
+		dio->iocb->ki_flags &= ~IOCB_HIPRI;
 	}
 
 	if (need_zeroout) {
-- 
2.27.0


  parent reply	other threads:[~2020-10-15  7:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15  7:40 [v2 0/2] block, iomap: disable iopoll for split bio Jeffle Xu
2020-10-15  7:40 ` [v2 1/2] block: " Jeffle Xu
2020-10-15  7:58   ` Christoph Hellwig
2020-10-15  7:40 ` Jeffle Xu [this message]
2020-10-15  7:59   ` [v2 2/2] block,iomap: disable iopoll when split needed Christoph Hellwig
2020-10-15  8:47     ` JeffleXu

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=20201015074031.91380-3-jefflexu@linux.alibaba.com \
    --to=jefflexu@linux.alibaba.com \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xiaoguang.wang@linux.alibaba.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).