add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
/*
|
|
|
|
|
* Hierarchical Bitmap Data Type
|
|
|
|
|
*
|
|
|
|
|
* Copyright Red Hat, Inc., 2012
|
|
|
|
|
*
|
|
|
|
|
* Author: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
|
*
|
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or
|
|
|
|
|
* later. See the COPYING file in the top-level directory.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef HBITMAP_H
|
2016-06-29 15:29:06 +02:00
|
|
|
#define HBITMAP_H
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
|
|
|
|
|
#include "bitops.h"
|
2013-02-14 02:47:36 +01:00
|
|
|
#include "host-utils.h"
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
|
|
|
|
|
typedef struct HBitmap HBitmap;
|
|
|
|
|
typedef struct HBitmapIter HBitmapIter;
|
|
|
|
|
|
|
|
|
|
#define BITS_PER_LEVEL (BITS_PER_LONG == 32 ? 5 : 6)
|
|
|
|
|
|
|
|
|
|
/* For 32-bit, the largest that fits in a 4 GiB address space.
|
|
|
|
|
* For 64-bit, the number of sectors in 1 PiB. Good luck, in
|
|
|
|
|
* either case... :)
|
|
|
|
|
*/
|
|
|
|
|
#define HBITMAP_LOG_MAX_SIZE (BITS_PER_LONG == 32 ? 34 : 41)
|
|
|
|
|
|
|
|
|
|
/* We need to place a sentinel in level 0 to speed up iteration. Thus,
|
|
|
|
|
* we do this instead of HBITMAP_LOG_MAX_SIZE / BITS_PER_LEVEL. The
|
|
|
|
|
* difference is that it allocates an extra level when HBITMAP_LOG_MAX_SIZE
|
|
|
|
|
* is an exact multiple of BITS_PER_LEVEL.
|
|
|
|
|
*/
|
|
|
|
|
#define HBITMAP_LEVELS ((HBITMAP_LOG_MAX_SIZE / BITS_PER_LEVEL) + 1)
|
|
|
|
|
|
|
|
|
|
struct HBitmapIter {
|
|
|
|
|
const HBitmap *hb;
|
|
|
|
|
|
|
|
|
|
/* Copied from hb for access in the inline functions (hb is opaque). */
|
|
|
|
|
int granularity;
|
|
|
|
|
|
|
|
|
|
/* Entry offset into the last-level array of longs. */
|
|
|
|
|
size_t pos;
|
|
|
|
|
|
|
|
|
|
/* The currently-active path in the tree. Each item of cur[i] stores
|
|
|
|
|
* the bits (i.e. the subtrees) yet to be processed under that node.
|
|
|
|
|
*/
|
|
|
|
|
unsigned long cur[HBITMAP_LEVELS];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_alloc:
|
|
|
|
|
* @size: Number of bits in the bitmap.
|
|
|
|
|
* @granularity: Granularity of the bitmap. Aligned groups of 2^@granularity
|
|
|
|
|
* bits will be represented by a single bit. Each operation on a
|
|
|
|
|
* range of bits first rounds the bits to determine which group they land
|
|
|
|
|
* in, and then affect the entire set; iteration will only visit the first
|
|
|
|
|
* bit of each group.
|
|
|
|
|
*
|
|
|
|
|
* Allocate a new HBitmap.
|
|
|
|
|
*/
|
|
|
|
|
HBitmap *hbitmap_alloc(uint64_t size, int granularity);
|
|
|
|
|
|
2015-04-18 01:50:03 +02:00
|
|
|
/**
|
|
|
|
|
* hbitmap_truncate:
|
|
|
|
|
* @hb: The bitmap to change the size of.
|
|
|
|
|
* @size: The number of elements to change the bitmap to accommodate.
|
|
|
|
|
*
|
|
|
|
|
* truncate or grow an existing bitmap to accommodate a new number of elements.
|
|
|
|
|
* This may invalidate existing HBitmapIterators.
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_truncate(HBitmap *hb, uint64_t size);
|
|
|
|
|
|
2015-04-18 01:49:55 +02:00
|
|
|
/**
|
|
|
|
|
* hbitmap_merge:
|
|
|
|
|
*
|
2018-10-29 21:23:15 +01:00
|
|
|
* Store result of merging @a and @b into @result.
|
|
|
|
|
* @result is allowed to be equal to @a or @b.
|
|
|
|
|
*
|
|
|
|
|
* Return true if the merge was successful,
|
|
|
|
|
* false if it was not attempted.
|
|
|
|
|
*/
|
|
|
|
|
bool hbitmap_merge(const HBitmap *a, const HBitmap *b, HBitmap *result);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_can_merge:
|
|
|
|
|
*
|
|
|
|
|
* hbitmap_can_merge(a, b) && hbitmap_can_merge(a, result) is sufficient and
|
|
|
|
|
* necessary for hbitmap_merge will not fail.
|
|
|
|
|
*
|
2015-04-18 01:49:55 +02:00
|
|
|
*/
|
2018-10-29 21:23:15 +01:00
|
|
|
bool hbitmap_can_merge(const HBitmap *a, const HBitmap *b);
|
2015-04-18 01:49:55 +02:00
|
|
|
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
/**
|
|
|
|
|
* hbitmap_empty:
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
*
|
|
|
|
|
* Return whether the bitmap is empty.
|
|
|
|
|
*/
|
|
|
|
|
bool hbitmap_empty(const HBitmap *hb);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_granularity:
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
*
|
|
|
|
|
* Return the granularity of the HBitmap.
|
|
|
|
|
*/
|
|
|
|
|
int hbitmap_granularity(const HBitmap *hb);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_count:
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
*
|
|
|
|
|
* Return the number of bits set in the HBitmap.
|
|
|
|
|
*/
|
|
|
|
|
uint64_t hbitmap_count(const HBitmap *hb);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_set:
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
* @start: First bit to set (0-based).
|
|
|
|
|
* @count: Number of bits to set.
|
|
|
|
|
*
|
|
|
|
|
* Set a consecutive range of bits in an HBitmap.
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_set(HBitmap *hb, uint64_t start, uint64_t count);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_reset:
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
* @start: First bit to reset (0-based).
|
|
|
|
|
* @count: Number of bits to reset.
|
|
|
|
|
*
|
|
|
|
|
* Reset a consecutive range of bits in an HBitmap.
|
2019-08-06 17:26:11 +02:00
|
|
|
* @start and @count must be aligned to bitmap granularity. The only exception
|
|
|
|
|
* is resetting the tail of the bitmap: @count may be equal to hb->orig_size -
|
|
|
|
|
* @start, in this case @count may be not aligned. The sum of @start + @count is
|
|
|
|
|
* allowed to be greater than hb->orig_size, but only if @start < hb->orig_size
|
|
|
|
|
* and @start + @count = ALIGN_UP(hb->orig_size, granularity).
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
*/
|
|
|
|
|
void hbitmap_reset(HBitmap *hb, uint64_t start, uint64_t count);
|
|
|
|
|
|
2015-05-22 03:29:46 +02:00
|
|
|
/**
|
|
|
|
|
* hbitmap_reset_all:
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
*
|
|
|
|
|
* Reset all bits in an HBitmap.
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_reset_all(HBitmap *hb);
|
|
|
|
|
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
/**
|
|
|
|
|
* hbitmap_get:
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
* @item: Bit to query (0-based).
|
|
|
|
|
*
|
|
|
|
|
* Return whether the @item-th bit in an HBitmap is set.
|
|
|
|
|
*/
|
|
|
|
|
bool hbitmap_get(const HBitmap *hb, uint64_t item);
|
|
|
|
|
|
2016-11-15 23:57:45 +01:00
|
|
|
/**
|
|
|
|
|
* hbitmap_is_serializable:
|
|
|
|
|
* @hb: HBitmap which should be (de-)serialized.
|
|
|
|
|
*
|
|
|
|
|
* Returns whether the bitmap can actually be (de-)serialized. Other
|
|
|
|
|
* (de-)serialization functions may only be invoked if this function returns
|
|
|
|
|
* true.
|
|
|
|
|
*
|
|
|
|
|
* Calling (de-)serialization functions does not affect a bitmap's
|
|
|
|
|
* (de-)serializability.
|
|
|
|
|
*/
|
|
|
|
|
bool hbitmap_is_serializable(const HBitmap *hb);
|
|
|
|
|
|
2016-10-13 23:58:27 +02:00
|
|
|
/**
|
2017-09-25 16:55:08 +02:00
|
|
|
* hbitmap_serialization_align:
|
2016-10-13 23:58:27 +02:00
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
*
|
2017-09-25 16:55:08 +02:00
|
|
|
* Required alignment of serialization chunks, used by other serialization
|
|
|
|
|
* functions. For every chunk:
|
2016-10-13 23:58:27 +02:00
|
|
|
* 1. Chunk start should be aligned to this granularity.
|
|
|
|
|
* 2. Chunk size should be aligned too, except for last chunk (for which
|
|
|
|
|
* start + count == hb->size)
|
|
|
|
|
*/
|
2017-09-25 16:55:08 +02:00
|
|
|
uint64_t hbitmap_serialization_align(const HBitmap *hb);
|
2016-10-13 23:58:27 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_serialization_size:
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
* @start: Starting bit
|
|
|
|
|
* @count: Number of bits
|
|
|
|
|
*
|
|
|
|
|
* Return number of bytes hbitmap_(de)serialize_part needs
|
|
|
|
|
*/
|
|
|
|
|
uint64_t hbitmap_serialization_size(const HBitmap *hb,
|
|
|
|
|
uint64_t start, uint64_t count);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_serialize_part
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
* @buf: Buffer to store serialized bitmap.
|
|
|
|
|
* @start: First bit to store.
|
|
|
|
|
* @count: Number of bits to store.
|
|
|
|
|
*
|
|
|
|
|
* Stores HBitmap data corresponding to given region. The format of saved data
|
|
|
|
|
* is linear sequence of bits, so it can be used by hbitmap_deserialize_part
|
|
|
|
|
* independently of endianness and size of HBitmap level array elements
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_serialize_part(const HBitmap *hb, uint8_t *buf,
|
|
|
|
|
uint64_t start, uint64_t count);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_deserialize_part
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
* @buf: Buffer to restore bitmap data from.
|
|
|
|
|
* @start: First bit to restore.
|
|
|
|
|
* @count: Number of bits to restore.
|
|
|
|
|
* @finish: Whether to call hbitmap_deserialize_finish automatically.
|
|
|
|
|
*
|
|
|
|
|
* Restores HBitmap data corresponding to given region. The format is the same
|
|
|
|
|
* as for hbitmap_serialize_part.
|
|
|
|
|
*
|
|
|
|
|
* If @finish is false, caller must call hbitmap_serialize_finish before using
|
|
|
|
|
* the bitmap.
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_deserialize_part(HBitmap *hb, uint8_t *buf,
|
|
|
|
|
uint64_t start, uint64_t count,
|
|
|
|
|
bool finish);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_deserialize_zeroes
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
* @start: First bit to restore.
|
|
|
|
|
* @count: Number of bits to restore.
|
|
|
|
|
* @finish: Whether to call hbitmap_deserialize_finish automatically.
|
|
|
|
|
*
|
|
|
|
|
* Fills the bitmap with zeroes.
|
|
|
|
|
*
|
|
|
|
|
* If @finish is false, caller must call hbitmap_serialize_finish before using
|
|
|
|
|
* the bitmap.
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_deserialize_zeroes(HBitmap *hb, uint64_t start, uint64_t count,
|
|
|
|
|
bool finish);
|
|
|
|
|
|
2017-06-28 14:05:06 +02:00
|
|
|
/**
|
|
|
|
|
* hbitmap_deserialize_ones
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
* @start: First bit to restore.
|
|
|
|
|
* @count: Number of bits to restore.
|
|
|
|
|
* @finish: Whether to call hbitmap_deserialize_finish automatically.
|
|
|
|
|
*
|
|
|
|
|
* Fills the bitmap with ones.
|
|
|
|
|
*
|
|
|
|
|
* If @finish is false, caller must call hbitmap_serialize_finish before using
|
|
|
|
|
* the bitmap.
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_deserialize_ones(HBitmap *hb, uint64_t start, uint64_t count,
|
|
|
|
|
bool finish);
|
|
|
|
|
|
2016-10-13 23:58:27 +02:00
|
|
|
/**
|
|
|
|
|
* hbitmap_deserialize_finish
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
*
|
|
|
|
|
* Repair HBitmap after calling hbitmap_deserialize_data. Actually, all HBitmap
|
|
|
|
|
* layers are restored here.
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_deserialize_finish(HBitmap *hb);
|
|
|
|
|
|
2017-06-28 14:05:25 +02:00
|
|
|
/**
|
|
|
|
|
* hbitmap_sha256:
|
|
|
|
|
* @bitmap: HBitmap to operate on.
|
|
|
|
|
*
|
|
|
|
|
* Returns SHA256 hash of the last level.
|
|
|
|
|
*/
|
|
|
|
|
char *hbitmap_sha256(const HBitmap *bitmap, Error **errp);
|
|
|
|
|
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
/**
|
|
|
|
|
* hbitmap_free:
|
|
|
|
|
* @hb: HBitmap to operate on.
|
|
|
|
|
*
|
|
|
|
|
* Free an HBitmap and all of its associated memory.
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_free(HBitmap *hb);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hbitmap_iter_init:
|
|
|
|
|
* @hbi: HBitmapIter to initialize.
|
|
|
|
|
* @hb: HBitmap to iterate on.
|
2013-01-22 15:01:12 +01:00
|
|
|
* @first: First bit to visit (0-based, must be strictly less than the
|
|
|
|
|
* size of the bitmap).
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
*
|
|
|
|
|
* Set up @hbi to iterate on the HBitmap @hb. hbitmap_iter_next will return
|
|
|
|
|
* the lowest-numbered bit that is set in @hb, starting at @first.
|
|
|
|
|
*
|
|
|
|
|
* Concurrent setting of bits is acceptable, and will at worst cause the
|
2017-06-28 14:05:03 +02:00
|
|
|
* iteration to miss some of those bits.
|
|
|
|
|
*
|
|
|
|
|
* The concurrent resetting of bits is OK.
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
*/
|
|
|
|
|
void hbitmap_iter_init(HBitmapIter *hbi, const HBitmap *hb, uint64_t first);
|
|
|
|
|
|
2020-02-05 12:20:37 +01:00
|
|
|
/*
|
|
|
|
|
* hbitmap_next_dirty:
|
|
|
|
|
*
|
|
|
|
|
* Find next dirty bit within selected range. If not found, return -1.
|
|
|
|
|
*
|
|
|
|
|
* @hb: The HBitmap to operate on
|
|
|
|
|
* @start: The bit to start from.
|
|
|
|
|
* @count: Number of bits to proceed. If @start+@count > bitmap size, the whole
|
|
|
|
|
* bitmap is looked through. You can use INT64_MAX as @count to search up to
|
|
|
|
|
* the bitmap end.
|
|
|
|
|
*/
|
|
|
|
|
int64_t hbitmap_next_dirty(const HBitmap *hb, int64_t start, int64_t count);
|
|
|
|
|
|
2017-10-12 15:53:09 +02:00
|
|
|
/* hbitmap_next_zero:
|
2019-01-16 00:26:49 +01:00
|
|
|
*
|
|
|
|
|
* Find next not dirty bit within selected range. If not found, return -1.
|
|
|
|
|
*
|
2017-10-12 15:53:09 +02:00
|
|
|
* @hb: The HBitmap to operate on
|
|
|
|
|
* @start: The bit to start from.
|
2019-01-16 00:26:49 +01:00
|
|
|
* @count: Number of bits to proceed. If @start+@count > bitmap size, the whole
|
2020-02-05 12:20:36 +01:00
|
|
|
* bitmap is looked through. You can use INT64_MAX as @count to search up to
|
2019-01-16 00:26:49 +01:00
|
|
|
* the bitmap end.
|
2017-10-12 15:53:09 +02:00
|
|
|
*/
|
2020-02-05 12:20:36 +01:00
|
|
|
int64_t hbitmap_next_zero(const HBitmap *hb, int64_t start, int64_t count);
|
2017-10-12 15:53:09 +02:00
|
|
|
|
2019-01-16 00:26:50 +01:00
|
|
|
/* hbitmap_next_dirty_area:
|
|
|
|
|
* @hb: The HBitmap to operate on
|
2020-02-05 12:20:38 +01:00
|
|
|
* @start: the offset to start from
|
|
|
|
|
* @end: end of requested area
|
|
|
|
|
* @max_dirty_count: limit for out parameter dirty_count
|
|
|
|
|
* @dirty_start: on success: start of found area
|
|
|
|
|
* @dirty_count: on success: length of found area
|
|
|
|
|
*
|
|
|
|
|
* If dirty area found within [@start, @end), returns true and sets
|
|
|
|
|
* @dirty_start and @dirty_count appropriately. @dirty_count will not exceed
|
|
|
|
|
* @max_dirty_count.
|
|
|
|
|
* If dirty area was not found, returns false and leaves @dirty_start and
|
|
|
|
|
* @dirty_count unchanged.
|
2019-01-16 00:26:50 +01:00
|
|
|
*/
|
2020-02-05 12:20:38 +01:00
|
|
|
bool hbitmap_next_dirty_area(const HBitmap *hb, int64_t start, int64_t end,
|
|
|
|
|
int64_t max_dirty_count,
|
|
|
|
|
int64_t *dirty_start, int64_t *dirty_count);
|
2019-01-16 00:26:50 +01:00
|
|
|
|
2022-03-03 20:43:41 +01:00
|
|
|
/*
|
|
|
|
|
* bdrv_dirty_bitmap_status:
|
|
|
|
|
* @hb: The HBitmap to operate on
|
|
|
|
|
* @start: The bit to start from
|
|
|
|
|
* @count: Number of bits to proceed
|
|
|
|
|
* @pnum: Out-parameter. How many bits has same value starting from @start
|
|
|
|
|
*
|
|
|
|
|
* Returns true if bitmap is dirty at @start, false otherwise.
|
|
|
|
|
*/
|
|
|
|
|
bool hbitmap_status(const HBitmap *hb, int64_t start, int64_t count,
|
|
|
|
|
int64_t *pnum);
|
|
|
|
|
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
/**
|
|
|
|
|
* hbitmap_iter_next:
|
|
|
|
|
* @hbi: HBitmapIter to operate on.
|
|
|
|
|
*
|
|
|
|
|
* Return the next bit that is set in @hbi's associated HBitmap,
|
|
|
|
|
* or -1 if all remaining bits are zero.
|
|
|
|
|
*/
|
2019-01-16 00:26:50 +01:00
|
|
|
int64_t hbitmap_iter_next(HBitmapIter *hbi);
|
add hierarchical bitmap data type and test cases
HBitmaps provides an array of bits. The bits are stored as usual in an
array of unsigned longs, but HBitmap is also optimized to provide fast
iteration over set bits; going from one bit to the next is O(logB n)
worst case, with B = sizeof(long) * CHAR_BIT: the result is low enough
that the number of levels is in fact fixed.
In order to do this, it stacks multiple bitmaps with progressively coarser
granularity; in all levels except the last, bit N is set iff the N-th
unsigned long is nonzero in the immediately next level. When iteration
completes on the last level it can examine the 2nd-last level to quickly
skip entire words, and even do so recursively to skip blocks of 64 words or
powers thereof (32 on 32-bit machines).
Given an index in the bitmap, it can be split in group of bits like
this (for the 64-bit case):
bits 0-57 => word in the last bitmap | bits 58-63 => bit in the word
bits 0-51 => word in the 2nd-last bitmap | bits 52-57 => bit in the word
bits 0-45 => word in the 3rd-last bitmap | bits 46-51 => bit in the word
So it is easy to move up simply by shifting the index right by
log2(BITS_PER_LONG) bits. To move down, you shift the index left
similarly, and add the word index within the group. Iteration uses
ffs (find first set bit) to find the next word to examine; this
operation can be done in constant time in most current architectures.
Setting or clearing a range of m bits on all levels, the work to perform
is O(m + m/W + m/W^2 + ...), which is O(m) like on a regular bitmap.
When iterating on a bitmap, each bit (on any level) is only visited
once. Hence, The total cost of visiting a bitmap with m bits in it is
the number of bits that are set in all bitmaps. Unless the bitmap is
extremely sparse, this is also O(m + m/W + m/W^2 + ...), so the amortized
cost of advancing from one bit to the next is usually constant.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2013-01-21 17:09:40 +01:00
|
|
|
|
|
|
|
|
#endif
|