From: Song Liu <song@kernel.org>
To: Jonathan Derrick <jonathan.derrick@linux.dev>
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
jonathan.derrick@solidigm.com, jonathanx.sk.derrick@intel.com
Subject: Re: [PATCH 2/2] md/bitmap: Add chunk-count-based bitmap flushing
Date: Fri, 7 Oct 2022 10:50:35 -0700 [thread overview]
Message-ID: <CAPhsuW6Ur8ic_u3nj9-TSpZ96jWqBa3GLEnw207sN8eJECYwZg@mail.gmail.com> (raw)
In-Reply-To: <20221006220840.275-4-jonathan.derrick@linux.dev>
On Thu, Oct 6, 2022 at 3:09 PM Jonathan Derrick
<jonathan.derrick@linux.dev> wrote:
[...]
> diff --git a/drivers/md/md-bitmap.h b/drivers/md/md-bitmap.h
> index cfd7395de8fd..e0aeedbdde17 100644
> --- a/drivers/md/md-bitmap.h
> +++ b/drivers/md/md-bitmap.h
> @@ -11,10 +11,12 @@
> /* version 4 insists the bitmap is in little-endian order
> * with version 3, it is host-endian which is non-portable
> * Version 5 is currently set only for clustered devices
> ++ * Version 6 supports the flush-chunks threshold
> */
> #define BITMAP_MAJOR_HI 4
> #define BITMAP_MAJOR_CLUSTERED 5
> #define BITMAP_MAJOR_HOSTENDIAN 3
> +#define BITMAP_MAJOR_CHUNKFLUSH 6
>
> /*
> * in-memory bitmap:
> @@ -135,7 +137,8 @@ typedef struct bitmap_super_s {
> * reserved for the bitmap. */
> __le32 nodes; /* 68 the maximum number of nodes in cluster. */
> __u8 cluster_name[64]; /* 72 cluster name to which this md belongs */
> - __u8 pad[256 - 136]; /* set to zero */
> + __le32 daemon_flush_chunks; /* 136 dirty chunks between flushes */
> + __u8 pad[256 - 140]; /* set to zero */
> } bitmap_super_t;
Do we really need this to be persistent? How about we configure it at run
time via a sysfs file?
Also, please share more data on the performance benefit of the set.
Thanks,
Song
>
> /* notes:
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index b4e2d8b87b61..d25574e46283 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -497,6 +497,7 @@ struct mddev {
> struct mutex mutex;
> unsigned long chunksize;
> unsigned long daemon_sleep; /* how many jiffies between updates? */
> + unsigned int daemon_flush_chunks; /* how many dirty chunks between updates */
> unsigned long max_write_behind; /* write-behind mode */
> int external;
> int nodes; /* Maximum number of nodes in the cluster */
> --
> 2.31.1
>
next prev parent reply other threads:[~2022-10-07 17:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-06 22:08 [PATCH 0/2] Bitmap percentage flushing Jonathan Derrick
2022-10-06 22:08 ` [RFC PATCH] mdadm: Add parameter for bitmap chunk threshold Jonathan Derrick
2022-10-12 7:17 ` Mariusz Tkaczyk
2022-10-06 22:08 ` [PATCH 1/2] md/bitmap: Move unplug to daemon thread Jonathan Derrick
2022-10-06 22:08 ` [PATCH 2/2] md/bitmap: Add chunk-count-based bitmap flushing Jonathan Derrick
2022-10-07 17:50 ` Song Liu [this message]
2022-10-07 18:58 ` Jonathan Derrick
2022-10-10 18:18 ` Song Liu
2022-10-13 22:19 ` Jonathan Derrick
2022-10-13 22:56 ` Song Liu
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=CAPhsuW6Ur8ic_u3nj9-TSpZ96jWqBa3GLEnw207sN8eJECYwZg@mail.gmail.com \
--to=song@kernel.org \
--cc=jonathan.derrick@linux.dev \
--cc=jonathan.derrick@solidigm.com \
--cc=jonathanx.sk.derrick@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
/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).