public inbox for linux-mediatek@lists.infradead.org
 help / color / mirror / Atom feed
From: <ed.tsai@mediatek.com>
To: Jens Axboe <axboe@kernel.dk>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>
Cc: <wsd_upstream@mediatek.com>, <stanley.chu@mediatek.com>,
	<peter.wang@mediatek.com>, <alice.chao@mediatek.com>,
	<powen.kao@mediatek.com>, <naomi.chu@mediatek.com>,
	<will.shiu@mediatek.com>, <chun-hung.wu@mediatek.com>,
	<casper.li@mediatek.com>, Ed Tsai <ed.tsai@mediatek.com>,
	<linux-block@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>
Subject: [PATCH 1/1] block: Check the queue limit before bio submitting
Date: Wed, 25 Oct 2023 17:22:52 +0800	[thread overview]
Message-ID: <20231025092255.27930-1-ed.tsai@mediatek.com> (raw)

From: Ed Tsai <ed.tsai@mediatek.com>

Referring to commit 07173c3ec276 ("block: enable multipage bvecs"),
each bio_vec now holds more than one page, potentially exceeding
1MB in size and causing alignment issues with the queue limit.

In a sequential read/write scenario, the file system maximizes the
bio's capacity before submitting. However, misalignment with the
queue limit can result in the bio being split into smaller I/O
operations.

For instance, assuming the maximum I/O size is set to 512KB and the
memory is highly fragmented, resulting in each bio containing only
one 2-pages bio_vec (i.e., bi_size = 1028KB). This would cause the
bio to be split into two 512KB portions and one 4KB portion. As a
result, the originally expected continuous large I/O operations are
interspersed with many small I/O operations.

To address this issue, this patch adds a check for the max_sectors
before submitting the bio. This allows the upper layers to proactively
detect and handle alignment issues.

I performed the Antutu V10 Storage Test on a UFS 4.0 device, which
resulted in a significant improvement in the Sequential test:

Sequential Read (average of 5 rounds):
Original: 3033.7 MB/sec
Patched: 3520.9 MB/sec

Sequential Write (average of 5 rounds):
Original: 2225.4 MB/sec
Patched: 2800.3 MB/sec

Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
---
 block/bio.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/block/bio.c b/block/bio.c
index 816d412c06e9..a4a1f775b9ea 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1227,6 +1227,7 @@ static int __bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter)
 	iov_iter_extraction_t extraction_flags = 0;
 	unsigned short nr_pages = bio->bi_max_vecs - bio->bi_vcnt;
 	unsigned short entries_left = bio->bi_max_vecs - bio->bi_vcnt;
+	struct queue_limits *lim = &bdev_get_queue(bio->bi_bdev)->limits;
 	struct bio_vec *bv = bio->bi_io_vec + bio->bi_vcnt;
 	struct page **pages = (struct page **)bv;
 	ssize_t size, left;
@@ -1275,6 +1276,11 @@ static int __bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter)
 		struct page *page = pages[i];
 
 		len = min_t(size_t, PAGE_SIZE - offset, left);
+		if (bio->bi_iter.bi_size + len >
+		    lim->max_sectors << SECTOR_SHIFT) {
+			ret = left;
+			break;
+		}
 		if (bio_op(bio) == REQ_OP_ZONE_APPEND) {
 			ret = bio_iov_add_zone_append_page(bio, page, len,
 					offset);
-- 
2.18.0



             reply	other threads:[~2023-10-25  9:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25  9:22 ed.tsai [this message]
2023-11-01  2:23 ` [PATCH 1/1] block: Check the queue limit before bio submitting Ed Tsai (蔡宗軒)
2023-11-03  8:15   ` Christoph Hellwig
2023-11-03  9:05     ` Ed Tsai (蔡宗軒)
2023-11-03 16:20   ` Ming Lei
2023-11-04  1:11     ` Ed Tsai (蔡宗軒)
2023-11-04  2:12       ` Yu Kuai
2023-11-04  3:43       ` Ming Lei
2023-11-06  1:33         ` Ed Tsai (蔡宗軒)
2023-11-06  1:40           ` Ed Tsai (蔡宗軒)
2023-11-06  4:53             ` Ming Lei
2023-11-06 11:54               ` Ming Lei
2023-11-07  2:53                 ` Ed Tsai (蔡宗軒)
2023-11-07  3:48                   ` Ming Lei
2023-11-07  4:35                     ` Ed Tsai (蔡宗軒)

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=20231025092255.27930-1-ed.tsai@mediatek.com \
    --to=ed.tsai@mediatek.com \
    --cc=alice.chao@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=axboe@kernel.dk \
    --cc=casper.li@mediatek.com \
    --cc=chun-hung.wu@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=naomi.chu@mediatek.com \
    --cc=peter.wang@mediatek.com \
    --cc=powen.kao@mediatek.com \
    --cc=stanley.chu@mediatek.com \
    --cc=will.shiu@mediatek.com \
    --cc=wsd_upstream@mediatek.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