From: Christoph Hellwig <hch@lst.de>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: Christoph Hellwig <hch@lst.de>,
xni@redhat.com, colyli@kernel.org, agk@redhat.com,
snitzer@kernel.org, mpatocka@redhat.com, song@kernel.org,
linux-kernel@vger.kernel.org, dm-devel@lists.linux.dev,
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 md-6.16 v3 15/19] md/md-llbitmap: implement APIs to dirty bits and clear bits
Date: Wed, 14 May 2025 07:17:47 +0200 [thread overview]
Message-ID: <20250514051747.GA24503@lst.de> (raw)
In-Reply-To: <d5ae7af0-dd73-7d6b-f520-c25e411f8f06@huaweicloud.com>
On Tue, May 13, 2025 at 05:32:13PM +0800, Yu Kuai wrote:
> I was thinking about record a stack dev depth in mddev to handle the
> weird case inside raid. Is there other stack device have the same
> problem? AFAIK, some dm targets like dm-crypt are using workqueue
> to handle all IO.
I guess anything that might have to read in metadata to serve a
data I/O. bcache, dm-snapshot and dm-thinkp would be candidates for
that, but I haven't checked the implementation.
> I'm still interested because this can improve first write latency.
>
>>
>> So instead just write a comment documenting why you switch to a
>> different stack using the workqueue.
>
> Ok, I'll add comment if we keep using the workqueue.
Maybe do that for getting the new bitmap code in ASAP and then
revisit the above separately?
next prev parent reply other threads:[~2025-05-14 5:17 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-12 1:19 [PATCH RFC md-6.16 v3 00/19] md: introduce a new lockless bitmap Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 01/19] md/md-bitmap: add {start, end}_discard in bitmap_operations Yu Kuai
2025-05-12 4:39 ` Christoph Hellwig
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 02/19] md: support discard for bitmap ops Yu Kuai
2025-05-12 4:41 ` Christoph Hellwig
2025-05-12 6:05 ` Yu Kuai
2025-05-12 6:12 ` Christoph Hellwig
2025-05-12 6:22 ` Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 03/19] md/md-bitmap: remove parameter slot from bitmap_create() Yu Kuai
2025-05-12 4:41 ` Christoph Hellwig
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 04/19] md: add a new sysfs api bitmap_version Yu Kuai
2025-05-12 4:51 ` Christoph Hellwig
2025-05-12 6:12 ` Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 05/19] md: delay registration of bitmap_ops until creating bitmap Yu Kuai
2025-05-12 4:53 ` Christoph Hellwig
2025-05-12 6:25 ` Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 06/19] md: add a new parameter 'offset' to md_super_write() Yu Kuai
2025-05-12 4:55 ` Christoph Hellwig
2025-05-12 6:32 ` Yu Kuai
2025-05-12 6:39 ` Christoph Hellwig
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 07/19] md/md-bitmap: add a new helper skip_sync_blocks() in bitmap_operations Yu Kuai
2025-05-12 4:56 ` Christoph Hellwig
2025-05-22 2:44 ` Xiao Ni
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 08/19] md/md-bitmap: add a new helper blocks_synced() " Yu Kuai
2025-05-12 4:57 ` Christoph Hellwig
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 09/19] md: add a new recovery_flag MD_RECOVERY_LAZY_RECOVER Yu Kuai
2025-05-12 4:57 ` Christoph Hellwig
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 10/19] md/md-llbitmap: add data structure definition and comments Yu Kuai
2025-05-12 5:09 ` Christoph Hellwig
2025-05-12 8:05 ` Yu Kuai
2025-05-12 13:24 ` Christoph Hellwig
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 11/19] md/md-llbitmap: implement bitmap IO Yu Kuai
2025-05-12 5:15 ` Christoph Hellwig
2025-05-12 8:15 ` Yu Kuai
2025-05-12 13:25 ` Christoph Hellwig
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 12/19] md/md-llbitmap: implement bit state machine Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 13/19] md/md-llbitmap: implement APIs for page level dirty bits synchronization Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 14/19] md/md-llbitmap: implement APIs to mange bitmap lifetime Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 15/19] md/md-llbitmap: implement APIs to dirty bits and clear bits Yu Kuai
2025-05-12 5:17 ` Christoph Hellwig
2025-05-12 8:23 ` Yu Kuai
2025-05-12 13:26 ` Christoph Hellwig
2025-05-12 13:30 ` Christoph Hellwig
2025-05-12 13:36 ` Yu Kuai
2025-05-13 6:32 ` Yu Kuai
2025-05-13 6:48 ` Christoph Hellwig
2025-05-13 7:14 ` Yu Kuai
2025-05-13 7:43 ` Christoph Hellwig
2025-05-13 9:32 ` Yu Kuai
2025-05-14 5:17 ` Christoph Hellwig [this message]
2025-05-15 13:38 ` Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 16/19] md/md-llbitmap: implement APIs for sync_thread Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 17/19] md/md-llbitmap: implement all bitmap operations Yu Kuai
2025-05-12 5:18 ` Christoph Hellwig
2025-05-12 8:28 ` Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 18/19] md/md-llbitmap: implement sysfs APIs Yu Kuai
2025-05-12 1:19 ` [PATCH RFC md-6.16 v3 19/19] md/md-llbitmap: add Kconfig Yu Kuai
2025-05-12 5:19 ` Christoph Hellwig
2025-05-12 8:30 ` Yu Kuai
2025-05-12 5:21 ` [PATCH RFC md-6.16 v3 00/19] md: introduce a new lockless bitmap Christoph Hellwig
2025-05-12 8:40 ` Yu Kuai
2025-05-12 13:27 ` Christoph Hellwig
2025-05-12 13:41 ` 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=20250514051747.GA24503@lst.de \
--to=hch@lst.de \
--cc=agk@redhat.com \
--cc=colyli@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=johnny.chenyi@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.org \
--cc=song@kernel.org \
--cc=xni@redhat.com \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.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).