linux-fsdevel.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 1/2] block: disable iopoll for split bio
Date: Thu, 15 Oct 2020 15:40:30 +0800	[thread overview]
Message-ID: <20201015074031.91380-2-jefflexu@linux.alibaba.com> (raw)
In-Reply-To: <20201015074031.91380-1-jefflexu@linux.alibaba.com>

IOpoll is initially for small size, latency sensitive IO.

It doesn't work well for big IO, especially when it needs to be split to
multiple bios. When it comes to bio split, the returned cookie of
__submit_bio_noacct_mq() is indeed the cookie of the last split bio. The
completion of *this* last split bio done by iopoll doesn't mean the whole
original bio has completed. Callers of iopoll still need to wait for
completion of other split bios.

Besides bio splitting may cause more trouble for iopoll which isn't
supposed to be used in case of big IO.

IOpoll for split bio may cause potential race if CPU migration happens
during bio submission. Since the returned cookie is that of the last
split bio of, polling on the corresponding hardware queue doesn't help
complete other split bios, if these split bios are enqueued into
different hardware queues. Since interrupts are disabled for polling
queues, the completion of these other split bios depends on timeout
mechanism, thus causing a potential IO hang.

IOpoll for split bio may also cause hang for sync polling. Currently
both the blkdev and iomap-based fs (ext4/xfs, etc) support sync polling
in direct IO routine. These routines will submit bio without REQ_NOWAIT
flag set, and then start sync polling in current process context. The
process may hang in blk_mq_get_tag() if the submitted bio has to be
split into multiple bios and can rapidly exhaust the queue depth. The
process are waiting for the completion of the previously allocated
requests, which should be done by the following polling, and thus causing
a deadlock.

To avoid these subtle trouble described above, just disable iopoll for
split bio.

Suggested-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
---
 block/blk-merge.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index bcf5e4580603..dafd5ec65545 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -279,6 +279,22 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
 	return NULL;
 split:
 	*segs = nsegs;
+
+	/*
+	 * IOpoll is initially for small size, latency sensitive IO.
+	 *
+	 * It doesn't work well for big IO, especially when it needs to be split to
+	 * multiple bios. When it comes to bio split, the returned cookie of
+	 * __submit_bio_noacct_mq() is indeed the cookie of the last split bio. The
+	 * completion of *this* last split bio done by polling doesn't mean the whole
+	 * original bio has completed. Callers of polling still need to wait for
+	 * completion of other split bios.
+	 *
+	 * Besides bio splitting may cause more trouble for iopoll which isn't supposed
+	 * to be used in case of big IO.
+	 */
+	bio->bi_opf &= ~REQ_HIPRI;
+
 	return bio_split(bio, sectors, GFP_NOIO, bs);
 }
 
-- 
2.27.0


  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 ` Jeffle Xu [this message]
2020-10-15  7:58   ` [v2 1/2] block: " Christoph Hellwig
2020-10-15  7:40 ` [v2 2/2] block,iomap: disable iopoll when split needed Jeffle Xu
2020-10-15  7:59   ` 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-2-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).