linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: hch@infradead.org, corbet@lwn.net, agk@redhat.com,
	snitzer@kernel.org, mpatocka@redhat.com, song@kernel.org,
	xni@redhat.com, hare@suse.de, linan122@huawei.com,
	colyli@kernel.org, linux-doc@vger.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 v6 md-6.18 11/11] md/md-llbitmap: introduce new lockless bitmap
Date: Wed, 27 Aug 2025 08:07:25 +0200	[thread overview]
Message-ID: <8eb5acff-4c21-4be8-8d3c-b98bd258ef99@molgen.mpg.de> (raw)
In-Reply-To: <65a2856a-7e2f-111a-c92e-7941206ad006@huaweicloud.com>

Dear Kuai,


Thank you for your reply.

Am 27.08.25 um 05:44 schrieb Yu Kuai:

> 在 2025/08/26 17:52, Paul Menzel 写道:
>> It’d be great if you could motivate, why a lockless bitmap is needed  
>> > compared to the current implemention.
> 
> Se the performance test, old bitmap have global spinlock and is bad with
> fast disk.

Yes, but it’s at the end, and not explicitly stated. Should you resend, 
it’d be great if you could add that.

> [snip the typo part]
> 
>> How can/should this patch be tested/benchmarked?
> 
> There is pending mdadm patch, rfc verion can be used. Will work on
> formal version after this set is applied.

Understood. Maybe add an URL to the mdadm patch. (Sorry, should I have 
missed it.)

>> --- a/drivers/md/md-bitmap.h
>> +++ b/drivers/md/md-bitmap.h
>> @@ -9,10 +9,26 @@
>>    #define BITMAP_MAGIC 0x6d746962
>> +/*
>> + * version 3 is host-endian order, this is deprecated and not used for new
>> + * array
>> + */
>> +#define BITMAP_MAJOR_LO        3
>> +#define BITMAP_MAJOR_HOSTENDIAN    3
>> +/* version 4 is little-endian order, the default value */
>> +#define BITMAP_MAJOR_HI        4
>> +/* version 5 is only used for cluster */
>> +#define BITMAP_MAJOR_CLUSTERED    5

>> Move this to the header in a separate patch?
> 
> I prefer not, old bitmap use this as well.
Hmm, I do not understand the answer, as it’s moved in this patch, why 
can’t it be moved in another? But it’s not that important.


Kind regards,

Paul

  reply	other threads:[~2025-08-27  6:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26  8:51 [PATCH v6 md-6.18 00/11] md/llbitmap: md/md-llbitmap: introduce a new lockless bitmap Yu Kuai
2025-08-26  8:51 ` [PATCH v6 md-6.18 01/11] md: add a new parameter 'offset' to md_super_write() Yu Kuai
2025-08-26  8:51 ` [PATCH v6 md-6.18 02/11] md: factor out a helper raid_is_456() Yu Kuai
2025-08-26  8:51 ` [PATCH v6 md-6.18 03/11] md/md-bitmap: support discard for bitmap ops Yu Kuai
2025-08-26  8:51 ` [PATCH v6 md-6.18 04/11] md: add a new mddev field 'bitmap_id' Yu Kuai
2025-08-26  8:51 ` [PATCH v6 md-6.18 05/11] md/md-bitmap: add a new sysfs api bitmap_type Yu Kuai
2025-08-26  8:52 ` [PATCH v6 md-6.18 06/11] md/md-bitmap: delay registration of bitmap_ops until creating bitmap Yu Kuai
2025-08-26  8:52 ` [PATCH v6 md-6.18 07/11] md/md-bitmap: add a new method skip_sync_blocks() in bitmap_operations Yu Kuai
2025-08-26  8:52 ` [PATCH v6 md-6.18 08/11] md/md-bitmap: add a new method blocks_synced() " Yu Kuai
2025-08-26  8:52 ` [PATCH v6 md-6.18 09/11] md: add a new recovery_flag MD_RECOVERY_LAZY_RECOVER Yu Kuai
2025-08-26  8:52 ` [PATCH v6 md-6.18 10/11] md/md-bitmap: make method bitmap_ops->daemon_work optional Yu Kuai
2025-08-26  8:52 ` [PATCH v6 md-6.18 11/11] md/md-llbitmap: introduce new lockless bitmap Yu Kuai
2025-08-26  9:52   ` Paul Menzel
2025-08-27  3:44     ` Yu Kuai
2025-08-27  6:07       ` Paul Menzel [this message]
2025-08-28  7:10         ` Yu Kuai
2025-08-28  4:15   ` Randy Dunlap
2025-08-28 11:24   ` Li Nan
2025-08-29  1:03     ` 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=8eb5acff-4c21-4be8-8d3c-b98bd258ef99@molgen.mpg.de \
    --to=pmenzel@molgen.mpg.de \
    --cc=agk@redhat.com \
    --cc=colyli@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dm-devel@lists.linux.dev \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=johnny.chenyi@huawei.com \
    --cc=linan122@huawei.com \
    --cc=linux-doc@vger.kernel.org \
    --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).