From: Christoph Hellwig <hch@infradead.org>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: song@kernel.org, linux-kernel@vger.kernel.org,
linux-raid@vger.kernel.org, yukuai3@huawei.com,
yi.zhang@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH RFC -next 00/26] md/md-bitmap: introduce bitmap_operations
Date: Tue, 13 Aug 2024 00:21:29 -0700 [thread overview]
Message-ID: <ZrsJeabpeFdXVfIb@infradead.org> (raw)
In-Reply-To: <20240810020854.797814-1-yukuai1@huaweicloud.com>
On Sat, Aug 10, 2024 at 10:08:28AM +0800, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.com>
>
> The background is that currently bitmap is using a global spin_lock,
> cauing lock contention and huge IO performance degration for all raid
> levels.
>
> However, it's impossible to implement a new lock free bitmap with
> current situation that md-bitmap exposes the internal implementation
> with lots of exported apis. Hence bitmap_operations is invented, to
> describe bitmap core implementation, and a new bitmap can be introduced
> with a new bitmap_operations, we only need to switch to the new one
> during initialization.
>
> And with this we can build bitmap as kernel module, but that's not
> our concern for now.
>
> Noted I just compile this patchset, not tested yet.
Refactoring the bitmap code to be modular seems like a good idea.
But I'd just turn this into plain function calls and maybe a hidden
data structure if you feel really fancy. No need to introduce expensive
indirect calls and a separate module.
next prev parent reply other threads:[~2024-08-13 7:21 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-10 2:08 [PATCH RFC -next 00/26] md/md-bitmap: introduce bitmap_operations Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 01/26] md/md-bitmap: introduce struct bitmap_operations Yu Kuai
2024-08-13 6:58 ` Mariusz Tkaczyk
2024-08-13 7:25 ` Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 02/26] md/md-bitmap: merge md_bitmap_create() into bitmap_operations Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 03/26] md/md-bitmap: merge md_bitmap_load() " Yu Kuai
2024-08-13 7:07 ` Mariusz Tkaczyk
2024-08-13 7:30 ` Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 04/26] md/md-bitmap: merge md_bitmap_destroy() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 05/26] md/md-bitmap: merge md_bitmap_flush() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 06/26] md/md-bitmap: don't expose md_bitmap_print_sb() Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 07/26] md/md-bitmap: merge md_bitmap_update_sb() into bitmap_operations Yu Kuai
2024-08-13 7:17 ` Mariusz Tkaczyk
2024-08-13 7:33 ` Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 08/26] md/md-bitmap: merge md_bitmap_status() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 09/26] md/md-bitmap: remove md_bitmap_setallbits() Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 10/26] md/md-bitmap: merge bitmap_write_all() into bitmap_operations Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 11/26] md/md-bitmap: merge md_bitmap_dirty_bits() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 12/26] md/md-bitmap: merge md_bitmap_startwrite() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 13/26] md/md-bitmap: merge md_bitmap_endwrite() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 14/26] md/md-bitmap: merge md_bitmap_start_sync() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 15/26] md/md-bitmap: merge md_bitmap_end_sync() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 16/26] md/md-bitmap: merge md_bitmap_close_sync() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 17/26] md/md-bitmap: mrege md_bitmap_cond_end_sync() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 18/26] md/md-bitmap: merge bitmap_sync_with_cluster() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 19/26] md/md-bitmap: merge md_bitmap_resize() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 20/26] md/md-bitmap: merge get_bitmap_from_slot() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 21/26] md/md-bitmap: merge md_bitmap_copy_from_slot() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 22/26] md/md-bitmap: merge md_bitmap_free() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 23/26] md/md-bitmap: merge md_bitmap_wait_behind_writes() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 24/26] md/md-bitmap: merge md_bitmap_daemon_work() " Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 25/26] md/md-bitmap: merge md_bitmap_unplug() and md_bitmap_unplug_async() Yu Kuai
2024-08-10 2:08 ` [PATCH RFC -next 26/26] md/md-bitmap: merge bitmap_unplug() into bitmap_operations Yu Kuai
2024-08-13 7:21 ` Christoph Hellwig [this message]
2024-08-13 7:36 ` [PATCH RFC -next 00/26] md/md-bitmap: introduce bitmap_operations 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=ZrsJeabpeFdXVfIb@infradead.org \
--to=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=song@kernel.org \
--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 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.