Linux-Block Archive on lore.kernel.org
 help / color / Atom feed
* [v2 0/2] block, iomap: disable iopoll for split bio
@ 2020-10-15  7:40 Jeffle Xu
  2020-10-15  7:40 ` [v2 1/2] block: " Jeffle Xu
  2020-10-15  7:40 ` [v2 2/2] block,iomap: disable iopoll when split needed Jeffle Xu
  0 siblings, 2 replies; 6+ messages in thread
From: Jeffle Xu @ 2020-10-15  7:40 UTC (permalink / raw)
  To: axboe, hch, viro
  Cc: linux-fsdevel, linux-block, ming.lei, joseph.qi, xiaoguang.wang

This patchset is to fix the potential hang occured in sync polling.

Please refer the following link for background info and the v1 patch:
https://patchwork.kernel.org/project/linux-block/patch/20201013084051.27255-1-jefflexu@linux.alibaba.com/

The first patch disables iopoll for split bio in block layer, which is
suggested by Ming Lei.

The second patch disables iopoll when one IO request need to be split into
multiple bios.

changes since v1:
- adopt the fix suggested by Ming Lei, to disable iopoll for split bio directly
- disable iopoll in direct IO routine of blkdev fs and iomap


Jeffle Xu (2):
  block: disable iopoll for split bio
  block,iomap: disable iopoll when split needed

 block/blk-merge.c    | 16 ++++++++++++++++
 fs/block_dev.c       |  7 +++++++
 fs/iomap/direct-io.c |  9 ++++++++-
 3 files changed, 31 insertions(+), 1 deletion(-)

-- 
2.27.0


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [v2 1/2] block: disable iopoll for split bio
  2020-10-15  7:40 [v2 0/2] block, iomap: disable iopoll for split bio Jeffle Xu
@ 2020-10-15  7:40 ` Jeffle Xu
  2020-10-15  7:58   ` Christoph Hellwig
  2020-10-15  7:40 ` [v2 2/2] block,iomap: disable iopoll when split needed Jeffle Xu
  1 sibling, 1 reply; 6+ messages in thread
From: Jeffle Xu @ 2020-10-15  7:40 UTC (permalink / raw)
  To: axboe, hch, viro
  Cc: linux-fsdevel, linux-block, ming.lei, joseph.qi, xiaoguang.wang

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [v2 2/2] block,iomap: disable iopoll when split needed
  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:40 ` Jeffle Xu
  2020-10-15  7:59   ` Christoph Hellwig
  1 sibling, 1 reply; 6+ messages in thread
From: Jeffle Xu @ 2020-10-15  7:40 UTC (permalink / raw)
  To: axboe, hch, viro
  Cc: linux-fsdevel, linux-block, ming.lei, joseph.qi, xiaoguang.wang

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [v2 1/2] block: disable iopoll for split bio
  2020-10-15  7:40 ` [v2 1/2] block: " Jeffle Xu
@ 2020-10-15  7:58   ` Christoph Hellwig
  0 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2020-10-15  7:58 UTC (permalink / raw)
  To: Jeffle Xu
  Cc: axboe, hch, viro, linux-fsdevel, linux-block, ming.lei,
	joseph.qi, xiaoguang.wang

> +
> +	/*
> +	 * 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

Please fix the various overly long lines.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [v2 2/2] block,iomap: disable iopoll when split needed
  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
  0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2020-10-15  7:59 UTC (permalink / raw)
  To: Jeffle Xu
  Cc: axboe, hch, viro, linux-fsdevel, linux-block, ming.lei,
	joseph.qi, xiaoguang.wang

On Thu, Oct 15, 2020 at 03:40:31PM +0800, Jeffle Xu wrote:
> 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;

more pages than BIO_MAX_PAGES don't imply a split because we can
physically merge pages into a single vector (yes, BIO_MAX_PAGES is
utterly misnamed now).

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [v2 2/2] block,iomap: disable iopoll when split needed
  2020-10-15  7:59   ` Christoph Hellwig
@ 2020-10-15  8:47     ` JeffleXu
  0 siblings, 0 replies; 6+ messages in thread
From: JeffleXu @ 2020-10-15  8:47 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: axboe, viro, linux-fsdevel, linux-block, ming.lei, joseph.qi,
	xiaoguang.wang


On 10/15/20 3:59 PM, Christoph Hellwig wrote:
> On Thu, Oct 15, 2020 at 03:40:31PM +0800, Jeffle Xu wrote:
>> 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;
> more pages than BIO_MAX_PAGES don't imply a split because we can
> physically merge pages into a single vector (yes, BIO_MAX_PAGES is
> utterly misnamed now).
Sorry I missed it, though the flow may be sometimes misleading -.-||

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` [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

Linux-Block Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-block/0 linux-block/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-block linux-block/ https://lore.kernel.org/linux-block \
		linux-block@vger.kernel.org
	public-inbox-index linux-block

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-block


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git