From: Yu Kuai <yukuai1@huaweicloud.com>
To: Christoph Hellwig <hch@infradead.org>, Yu Kuai <yukuai1@huaweicloud.com>
Cc: colyli@kernel.org, hare@suse.de, tieren@fnnas.com,
axboe@kernel.dk, tj@kernel.org, josef@toxicpanda.com,
song@kernel.org, akpm@linux-foundation.org, neil@brown.name,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, linux-raid@vger.kernel.org,
yi.zhang@huawei.com, yangerkun@huawei.com,
johnny.chenyi@huawei.com, "yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH RFC 2/7] md/raid0: convert raid0_handle_discard() to use bio_submit_split()
Date: Tue, 26 Aug 2025 17:11:19 +0800 [thread overview]
Message-ID: <8f33c7b8-81bb-f167-b7a1-2783c20ede6f@huaweicloud.com> (raw)
In-Reply-To: <aK1oLSppbXNELKCX@infradead.org>
Hi,
在 2025/08/26 15:54, Christoph Hellwig 写道:
> On Tue, Aug 26, 2025 at 09:08:33AM +0800, Yu Kuai wrote:
>> 在 2025/08/25 18:57, Christoph Hellwig 写道:
>>> On Mon, Aug 25, 2025 at 05:36:55PM +0800, Yu Kuai wrote:
>>>> + bio = bio_submit_split(bio,
>>>> + zone->zone_end - bio->bi_iter.bi_sector,
>>>> + &mddev->bio_set);
>>>
>>> Do you know why raid0 and linear use mddev->bio_set for splitting
>>> instead of their own split bio_sets like raid1/10/5? Is this safe?
>>>
>>
>> I think it's not safe, as mddev->bio_split pool size is just 2, reuse
>> this pool to split multiple times before submitting will need greate
>> pool size to make this work.
>>
>> By the way, do you think it's better to increate disk->bio_split pool
>> size to 4 and convert all mdraid internal split to use disk->bio_split
>> directly?
>
> I don't really know where that magic number 4 or even the current number
> comes from, but I think Jens might be amenable to a small increase with a
> good explanation.
I was thinking we have to make sure issuing the allocated split bio
before allocating new bio, and that number is the safe limit that we can
allocated before issuing.
In case of recursive split, we can hold multiple split bio in
curent->bio_list, and with this set to handle split bio first, we can
gurantee we'll at most hold 3 split bios from mdraid:
- bio_split_to_limits(), for example, by max_sectors
- bio_split() by internal chunksize
- bio_split() by badblocks
That's why I said 4 should be safe :) If genddisk->bio_split can be
expanded to 4, all internal bio_split can be removed now.
Thanks,
Kuai
>
> .
>
next prev parent reply other threads:[~2025-08-26 9:11 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 9:36 [PATCH RFC 0/7] block: fix disordered IO in the case recursive split Yu Kuai
2025-08-25 9:36 ` [PATCH RFC 1/7] block: export helper bio_submit_split() Yu Kuai
2025-08-25 10:53 ` Christoph Hellwig
2025-08-26 0:51 ` Yu Kuai
2025-08-25 9:36 ` [PATCH RFC 2/7] md/raid0: convert raid0_handle_discard() to use bio_submit_split() Yu Kuai
2025-08-25 10:57 ` Christoph Hellwig
2025-08-26 1:08 ` Yu Kuai
2025-08-26 7:54 ` Christoph Hellwig
2025-08-26 9:11 ` Yu Kuai [this message]
2025-08-25 9:36 ` [PATCH RFC 3/7] md/raid1: convert " Yu Kuai
2025-08-25 10:57 ` Christoph Hellwig
2025-08-26 1:09 ` Yu Kuai
2025-08-25 9:36 ` [PATCH RFC 4/7] md/raid10: convert read/write " Yu Kuai
2025-08-25 10:59 ` Christoph Hellwig
2025-08-26 1:13 ` Yu Kuai
2025-08-26 7:55 ` Christoph Hellwig
2025-08-26 9:14 ` Yu Kuai
2025-08-26 17:35 ` anthony
2025-08-27 7:31 ` Christoph Hellwig
2025-09-02 6:18 ` John Garry
2025-09-02 6:30 ` Christoph Hellwig
2025-09-02 6:58 ` John Garry
2025-09-02 8:25 ` Yu Kuai
2025-09-02 14:46 ` John Garry
2025-08-25 9:36 ` [PATCH RFC 5/7] md/raid5: convert " Yu Kuai
2025-08-25 11:00 ` Christoph Hellwig
2025-08-26 1:15 ` Yu Kuai
2025-08-26 7:56 ` Christoph Hellwig
2025-08-25 9:36 ` [PATCH RFC 6/7] md/md-linear: " Yu Kuai
2025-08-25 9:37 ` [PATCH RFC 7/7] block: fix disordered IO in the case recursive split Yu Kuai
2025-08-25 11:07 ` Christoph Hellwig
2025-08-26 1:20 ` Yu Kuai
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=8f33c7b8-81bb-f167-b7a1-2783c20ede6f@huaweicloud.com \
--to=yukuai1@huaweicloud.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=colyli@kernel.org \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=johnny.chenyi@huawei.com \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neil@brown.name \
--cc=song@kernel.org \
--cc=tieren@fnnas.com \
--cc=tj@kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--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 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).