From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz, Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/3] btrfs: use integrated bitmaps for btrfs_raid_bio::dbitmap and finish_pbitmap
Date: Sat, 28 May 2022 07:27:29 +0800 [thread overview]
Message-ID: <e2fea10c-2188-5bd2-5e37-ca1662507a73@gmx.com> (raw)
In-Reply-To: <20220527140930.GD20633@twin.jikos.cz>
On 2022/5/27 22:09, David Sterba wrote:
> On Fri, May 27, 2022 at 03:28:17PM +0800, Qu Wenruo wrote:
>> Previsouly we use "unsigned long *" for those two bitmaps.
>>
>> But since we only support fixed stripe length (64KiB, already checked in
>> tree-checker), "unsigned long *" is really a waste of memory, while we
>> can just use "unsigned long".
>>
>> This saves us 8 bytes in total for btrfs_raid_bio.
>
> Nice, also the indirection of pointers and kmalloc, for 8 bytes it's an
> overkill. If we ever implement bigger stripe size then it would have to
> be reverted but the asserts make sure we'll notice.
In fact, even if we enlarge the STRIPE_LEN to 128K, the bitmap is still
enough to contain them.
Furthermore, in that enlarged case, tree-checker will be the first one
to warn us.
Thanks,
Qu
next prev parent reply other threads:[~2022-05-27 23:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-27 7:28 [PATCH 0/3] btrfs: raid56: reduce unnecessary parity writes Qu Wenruo
2022-05-27 7:28 ` [PATCH 1/3] btrfs: use integrated bitmaps for btrfs_raid_bio::dbitmap and finish_pbitmap Qu Wenruo
2022-05-27 14:09 ` David Sterba
2022-05-27 23:27 ` Qu Wenruo [this message]
2022-05-27 7:28 ` [PATCH 2/3] btrfs: use integrated bitmaps for scrub_parity::dbitmap and ebitmap Qu Wenruo
2022-05-27 7:28 ` [PATCH 3/3] btrfs: only write the sectors in the vertical stripe which has data stripes Qu Wenruo
2022-05-31 10:42 ` Qu Wenruo
2022-05-27 14:08 ` [PATCH 0/3] btrfs: raid56: reduce unnecessary parity writes David Sterba
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=e2fea10c-2188-5bd2-5e37-ca1662507a73@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.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.