From: Omar Sandoval <osandov@osandov.com>
To: Nikolay Borisov <nborisov@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/6] btrfs-progs: Add extent buffer bitmap manipulation infrastructure
Date: Fri, 21 Sep 2018 13:08:34 -0700 [thread overview]
Message-ID: <20180921200834.GC31081@vader> (raw)
In-Reply-To: <1529060762-4372-3-git-send-email-nborisov@suse.com>
On Fri, Jun 15, 2018 at 02:05:58PM +0300, Nikolay Borisov wrote:
> Those functions are in preparation for adding the freespace tree
> repair code since it needs to be able to deal with bitmap based fsts.
> This patch adds extent_buffer_bitmap_set and extent_buffer_bitmap_clear
> functions. Since in userspace we don't have to deal with page mappings
> their implementation is vastly simplified by simply setting each bit in
> the passed range.
>
> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
> ---
> extent_io.c | 39 +++++++++++++++++++++++++++++++++++++++
> extent_io.h | 15 +++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/extent_io.c b/extent_io.c
> index 198492699438..568a12f7084b 100644
> --- a/extent_io.c
> +++ b/extent_io.c
> @@ -204,6 +204,45 @@ static int clear_state_bit(struct extent_io_tree *tree,
> return ret;
> }
>
> +/**
> + * extent_buffer_bitmap_set - set an area of a bitmap
> + * @eb: the extent buffer
> + * @start: offset of the bitmap item in the extent buffer
> + * @pos: bit number of the first bit
> + * @len: number of bits to set
> + */
> +void extent_buffer_bitmap_set(struct extent_buffer *eb, unsigned long start,
> + unsigned long pos, unsigned long len)
> +{
> + u8 *kaddr = (u8 *)eb->data + start;
> +
> + while (len) {
> + le_set_bit(pos, kaddr);
> + pos++;
> + len--;
> + }
> +}
> +
> +
> +/**
> + * extent_buffer_bitmap_clear - clear an area of a bitmap
> + * @eb: the extent buffer
> + * @start: offset of the bitmap item in the extent buffer
> + * @pos: bit number of the first bit
> + * @len: number of bits to clear
> + */
> +void extent_buffer_bitmap_clear(struct extent_buffer *eb, unsigned long start,
> + unsigned long pos, unsigned long len)
> +{
> + u8 *kaddr = (u8 *)eb->data + start;
> +
> + while (len) {
> + le_clear_bit(pos, kaddr);
> + pos++;
> + len--;
> + }
> +}
> +
Hm, bit-by-bit is pretty slow. We don't have to worry about the kmap
nonsense, but we can still do this byte-by-byte:
/**
* extent_buffer_bitmap_set - set an area of a bitmap
* @eb: the extent buffer
* @start: offset of the bitmap item in the extent buffer
* @pos: bit number of the first bit
* @len: number of bits to set
*/
void extent_buffer_bitmap_set(struct extent_buffer *eb, unsigned long start,
unsigned long pos, unsigned long len)
{
u8 *p = (u8 *)eb->data + start + BIT_BYTE(pos);
const unsigned int size = pos + len;
int bits_to_set = BITS_PER_BYTE - (pos % BITS_PER_BYTE);
u8 mask_to_set = BITMAP_FIRST_BYTE_MASK(pos);
while (len >= bits_to_set) {
*p |= mask_to_set;
len -= bits_to_set;
bits_to_set = BITS_PER_BYTE;
mask_to_set = ~0;
p++;
}
if (len) {
mask_to_set &= BITMAP_LAST_BYTE_MASK(size);
*p |= mask_to_set;
}
}
/**
* extent_buffer_bitmap_clear - clear an area of a bitmap
* @eb: the extent buffer
* @start: offset of the bitmap item in the extent buffer
* @pos: bit number of the first bit
* @len: number of bits to clear
*/
void extent_buffer_bitmap_clear(struct extent_buffer *eb, unsigned long start,
unsigned long pos, unsigned long len)
{
u8 *p = (u8 *)eb->data + start + BIT_BYTE(pos);
const unsigned int size = pos + len;
int bits_to_clear = BITS_PER_BYTE - (pos % BITS_PER_BYTE);
u8 mask_to_clear = BITMAP_FIRST_BYTE_MASK(pos);
while (len >= bits_to_clear) {
*p &= ~mask_to_clear;
len -= bits_to_clear;
bits_to_clear = BITS_PER_BYTE;
mask_to_clear = ~0;
p++;
}
if (len) {
mask_to_clear &= BITMAP_LAST_BYTE_MASK(size);
*p &= ~mask_to_clear;
}
}
I'm 95% sure that's right ;) Compare to __bitmap_set() and
__bitmap_clear() in the kernel.
next prev parent reply other threads:[~2018-09-22 1:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 11:05 [PATCH 0/6] Freespace tree repair support Nikolay Borisov
2018-06-15 11:05 ` [PATCH 1/6] btrfs-progs: Add support for freespace tree in btrfs_read_fs_root Nikolay Borisov
2018-09-21 19:50 ` Omar Sandoval
2018-06-15 11:05 ` [PATCH 2/6] btrfs-progs: Add extent buffer bitmap manipulation infrastructure Nikolay Borisov
2018-09-21 20:08 ` Omar Sandoval [this message]
2018-06-15 11:05 ` [PATCH 3/6] btrfs-progs: Pull free space tree related code from kernel Nikolay Borisov
2018-09-21 20:19 ` Omar Sandoval
2018-09-21 20:38 ` Nikolay Borisov
2018-06-15 11:06 ` [PATCH 4/6] btrfs-progs: Add freespace tree as compat_ro supported feature Nikolay Borisov
2018-09-21 20:39 ` Omar Sandoval
2018-06-15 11:06 ` [PATCH 5/6] btrfs-progs: check: Add support for freespace tree fixing Nikolay Borisov
2018-09-21 20:42 ` Omar Sandoval
2018-06-15 11:06 ` [PATCH 6/6] btrfs-progs: tests: Test for FST corruption detection/repair Nikolay Borisov
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=20180921200834.GC31081@vader \
--to=osandov@osandov.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@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.