From: Christoph Hellwig <hch@lst.de>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: hch@lst.de, xni@redhat.com, colyli@kernel.org, agk@redhat.com,
snitzer@kernel.org, mpatocka@redhat.com, song@kernel.org,
yukuai3@huawei.com, 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
Subject: Re: [PATCH RFC md-6.16 v3 10/19] md/md-llbitmap: add data structure definition and comments
Date: Mon, 12 May 2025 07:09:50 +0200 [thread overview]
Message-ID: <20250512050950.GJ868@lst.de> (raw)
In-Reply-To: <20250512011927.2809400-11-yukuai1@huaweicloud.com>
On Mon, May 12, 2025 at 09:19:18AM +0800, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.com>
>
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
You'll need a commit message here. Also given how tiny this is
vs the rest of the file I'm not entirely sure there is much of a
point in splittng it out.
> +#include <linux/buffer_head.h>
This shouldn't be needed here I think.
> + * llbitmap state machine: transitions between states
Can you split the table below into two columns so that it's easily
readabe?
> +#define LLBITMAP_MAJOR_HI 6
I think you'll want to consolidate all the different version in
md-bitmap.h and document them.
> +#define BITMAP_MAX_SECTOR (128 * 2)
This appears unused even with the later series.
> +#define BITMAP_MAX_PAGES 32
Can you comment on how we ended up with this number?
> +#define BITMAP_SB_SIZE 1024
I'd add this to md-bitmap.h as it's part of the on-disk format, and
also make md-bitmap.c use it.
> +#define DEFAULT_DAEMON_SLEEP 30
> +
> +#define BARRIER_IDLE 5
Can you document these?
> +enum llbitmap_action {
> + /* User write new data, this is the only acton from IO fast path */
s/acton/action/
> +/*
> + * page level barrier to synchronize between dirty bit by write IO and clean bit
> + * by daemon.
Overly lon line. Also please stat full sentences with a capitalized
word.
> + */
> +struct llbitmap_barrier {
> + char *data;
This is really a states array as far as I can tell. Maybe name it
more descriptively and throw in a comment.
> + struct percpu_ref active;
> + unsigned long expire;
> + unsigned long flags;
> + /* Per block size dirty state, maximum 64k page / 512 sector = 128 */
> + DECLARE_BITMAP(dirty, 128);
> + wait_queue_head_t wait;
> +} ____cacheline_aligned_in_smp;
> +
> +struct llbitmap {
> + struct mddev *mddev;
> + int nr_pages;
> + struct page *pages[BITMAP_MAX_PAGES];
> + struct llbitmap_barrier barrier[BITMAP_MAX_PAGES];
Should the bitmap and the page be in the same array to have less
cache line sharing between the users/ The above
____cacheline_aligned_in_smp suggests you are at least somewhat
woerried about cache line sharing.
> +static char state_machine[nr_llbitmap_state][nr_llbitmap_action] = {
> + [BitUnwritten] = {BitDirty, BitNone, BitNone, BitNone, BitNone, BitNone, BitNone, BitNone},
Maybe used named initializers to make this more readable. In fact that
might remove the need for the big table in the comment at the top of the
file because it would be just as readable.
next prev parent reply other threads:[~2025-05-12 5:09 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 [this message]
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
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=20250512050950.GJ868@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 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.