From patchwork Thu Oct 15 07:40:30 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jingbo Xu X-Patchwork-Id: 11838767 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 518FB14B2 for ; Thu, 15 Oct 2020 07:40:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36ECE22261 for ; Thu, 15 Oct 2020 07:40:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728454AbgJOHkh (ORCPT ); Thu, 15 Oct 2020 03:40:37 -0400 Received: from out30-54.freemail.mail.aliyun.com ([115.124.30.54]:35124 "EHLO out30-54.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728036AbgJOHkf (ORCPT ); Thu, 15 Oct 2020 03:40:35 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0UC4rANt_1602747632; Received: from localhost(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0UC4rANt_1602747632) by smtp.aliyun-inc.com(127.0.0.1); Thu, 15 Oct 2020 15:40:32 +0800 From: Jeffle Xu 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 Message-Id: <20201015074031.91380-2-jefflexu@linux.alibaba.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201015074031.91380-1-jefflexu@linux.alibaba.com> References: <20201015074031.91380-1-jefflexu@linux.alibaba.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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 Signed-off-by: Jeffle Xu --- 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); } From patchwork Thu Oct 15 07:40:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jingbo Xu X-Patchwork-Id: 11838773 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0C9CE16BC for ; Thu, 15 Oct 2020 07:40:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EAECA22264 for ; Thu, 15 Oct 2020 07:40:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728036AbgJOHki (ORCPT ); Thu, 15 Oct 2020 03:40:38 -0400 Received: from out30-57.freemail.mail.aliyun.com ([115.124.30.57]:51410 "EHLO out30-57.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726103AbgJOHki (ORCPT ); Thu, 15 Oct 2020 03:40:38 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R561e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0UC4gbiG_1602747632; Received: from localhost(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0UC4gbiG_1602747632) by smtp.aliyun-inc.com(127.0.0.1); Thu, 15 Oct 2020 15:40:32 +0800 From: Jeffle Xu 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 Message-Id: <20201015074031.91380-3-jefflexu@linux.alibaba.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201015074031.91380-1-jefflexu@linux.alibaba.com> References: <20201015074031.91380-1-jefflexu@linux.alibaba.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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 --- 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) {