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:
|
|
|
|
|
* @a: The bitmap to store the result in.
|
|
|
|
|
* @b: The bitmap to merge into @a.
|
|
|
|
|
* @return true if the merge was successful,
|
|
|
|
|
* false if it was not attempted.
|
|
|
|
|
*
|
|
|
|
|
* Merge two bitmaps together.
|
|
|
|
|
* A := A (BITOR) B.
|
|
|
|
|
* B is left unmodified.
|
|
|
|
|
*/
|
|
|
|
|
bool hbitmap_merge(HBitmap *a, const HBitmap *b);
|
|
|
|
|
|
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.
|
|
|
|
|
*/
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
|
|
/* hbitmap_iter_skip_words:
|
|
|
|
|
* @hbi: HBitmapIter to operate on.
|
|
|
|
|
*
|
|
|
|
|
* Internal function used by hbitmap_iter_next and hbitmap_iter_next_word.
|
|
|
|
|
*/
|
|
|
|
|
unsigned long hbitmap_iter_skip_words(HBitmapIter *hbi);
|
|
|
|
|
|
2017-10-12 15:53:09 +02:00
|
|
|
/* hbitmap_next_zero:
|
|
|
|
|
* @hb: The HBitmap to operate on
|
|
|
|
|
* @start: The bit to start from.
|
|
|
|
|
*
|
|
|
|
|
* Find next not dirty bit.
|
|
|
|
|
*/
|
|
|
|
|
int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start);
|
|
|
|
|
|
2016-10-13 23:58:22 +02:00
|
|
|
/* hbitmap_create_meta:
|
|
|
|
|
* Create a "meta" hbitmap to track dirtiness of the bits in this HBitmap.
|
|
|
|
|
* The caller owns the created bitmap and must call hbitmap_free_meta(hb) to
|
|
|
|
|
* free it.
|
|
|
|
|
*
|
|
|
|
|
* Currently, we only guarantee that if a bit in the hbitmap is changed it
|
|
|
|
|
* will be reflected in the meta bitmap, but we do not yet guarantee the
|
|
|
|
|
* opposite.
|
|
|
|
|
*
|
|
|
|
|
* @hb: The HBitmap to operate on.
|
|
|
|
|
* @chunk_size: How many bits in @hb does one bit in the meta track.
|
|
|
|
|
*/
|
|
|
|
|
HBitmap *hbitmap_create_meta(HBitmap *hb, int chunk_size);
|
|
|
|
|
|
|
|
|
|
/* hbitmap_free_meta:
|
|
|
|
|
* Free the meta bitmap of @hb.
|
|
|
|
|
*
|
|
|
|
|
* @hb: The HBitmap whose meta bitmap should be freed.
|
|
|
|
|
*/
|
|
|
|
|
void hbitmap_free_meta(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_iter_next:
|
|
|
|
|
* @hbi: HBitmapIter to operate on.
|
2018-06-13 20:18:16 +02:00
|
|
|
* @advance: If true, advance the iterator. Otherwise, the next call
|
|
|
|
|
* of this function will return the same result (if that
|
|
|
|
|
* position is still dirty).
|
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
|
|
|
*
|
|
|
|
|
* Return the next bit that is set in @hbi's associated HBitmap,
|
|
|
|
|
* or -1 if all remaining bits are zero.
|
|
|
|
|
*/
|
2018-06-13 20:18:16 +02:00
|
|
|
int64_t hbitmap_iter_next(HBitmapIter *hbi, bool advance);
|
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_word:
|
|
|
|
|
* @hbi: HBitmapIter to operate on.
|
|
|
|
|
* @p_cur: Location where to store the next non-zero word.
|
|
|
|
|
*
|
|
|
|
|
* Return the index of the next nonzero word that is set in @hbi's
|
|
|
|
|
* associated HBitmap, and set *p_cur to the content of that word
|
|
|
|
|
* (bits before the index that was passed to hbitmap_iter_init are
|
|
|
|
|
* trimmed on the first call). Return -1, and set *p_cur to zero,
|
|
|
|
|
* if all remaining words are zero.
|
|
|
|
|
*/
|
|
|
|
|
static inline size_t hbitmap_iter_next_word(HBitmapIter *hbi, unsigned long *p_cur)
|
|
|
|
|
{
|
|
|
|
|
unsigned long cur = hbi->cur[HBITMAP_LEVELS - 1];
|
|
|
|
|
|
|
|
|
|
if (cur == 0) {
|
|
|
|
|
cur = hbitmap_iter_skip_words(hbi);
|
|
|
|
|
if (cur == 0) {
|
|
|
|
|
*p_cur = 0;
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The next call will resume work from the next word. */
|
|
|
|
|
hbi->cur[HBITMAP_LEVELS - 1] = 0;
|
|
|
|
|
*p_cur = cur;
|
|
|
|
|
return hbi->pos;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#endif
|