From: Christoph Hellwig <hch@infradead.org>
To: colyli@kernel.org
Cc: linux-raid@vger.kernel.org, linux-block@vger.kernel.org,
yukuai3@huawei.com
Subject: Re: [PATCH 2/2] md: split bio by io_opt size in md_submit_bio()
Date: Mon, 18 Aug 2025 01:01:37 -0700 [thread overview]
Message-ID: <aKLd4bj6QSzzXqSh@infradead.org> (raw)
In-Reply-To: <20250817152645.7115-2-colyli@kernel.org>
On Sun, Aug 17, 2025 at 11:26:45PM +0800, colyli@kernel.org wrote:
> This patch introduces bio_split_by_io_opt() to solve the above issue,
> 1, If the incoming bio is not limits.io_opt aligned, split the non-
> aligned head part. Then the next one will be aligned.
> 2, If the imcoming bio is limits.io_opt aligned, and split is necessary,
> then try to split a by multiple of limits.io_opt but not exceed
> limits.max_hw_sectors.
>
> Then for large bio, the sligned split part will be full-stripes covered
> to all data disks, no extra read-in I/Os when rmw_level is 0. And for
> rmw_level > 0 condistions, the limits.io_opt aligned bios are welcomed
> for performace as well.
>
> This patch only tests on 8 disks raid5 array with 64KiB chunk size.
> By this patch, 64KiB chunk size for a 8 disks raid5 array, sequential
> write performance increases from 900MiB/s to 1.1GiB/s by fio bs=10M.
> If fio bs=488K (exact limits.io_opt size) the peak sequential write
> throughput can reach 1.51GiB/s.
All this code duplication seems like a bad idea. What is the problem
with setting max_hw_sectors to a stripe size aligned value and then
letting bio_split_by_io_opt do the work?
next prev parent reply other threads:[~2025-08-18 8:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-17 15:26 [PATCH 1/2] block: ignore underlying non-stack devices io_opt colyli
2025-08-17 15:26 ` [PATCH 2/2] md: split bio by io_opt size in md_submit_bio() colyli
2025-08-18 1:38 ` Yu Kuai
2025-08-18 8:01 ` Christoph Hellwig [this message]
2025-08-18 9:51 ` John Garry
[not found] ` <6DA25F37-26B3-4912-90A3-346CFD9A6EEA@coly.li>
2025-08-18 12:20 ` John Garry
2025-08-18 15:36 ` Coly Li
2025-08-17 18:37 ` [PATCH 1/2] block: ignore underlying non-stack devices io_opt Paul Menzel
2025-08-18 1:14 ` Yu Kuai
2025-08-18 2:51 ` Damien Le Moal
2025-08-18 2:57 ` Yu Kuai
2025-08-18 3:18 ` Damien Le Moal
2025-08-18 3:40 ` Yu Kuai
2025-08-18 5:56 ` Christoph Hellwig
2025-08-18 6:14 ` Yu Kuai
2025-08-18 6:18 ` Christoph Hellwig
2025-08-18 6:31 ` Yu Kuai
2025-08-18 8:00 ` Christoph Hellwig
2025-08-18 8:10 ` Yu Kuai
2025-08-18 8:14 ` Christoph Hellwig
2025-08-18 8:57 ` Yu Kuai
2025-08-18 9:08 ` Christoph Hellwig
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=aKLd4bj6QSzzXqSh@infradead.org \
--to=hch@infradead.org \
--cc=colyli@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=yukuai3@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.