20.06.2019 4:03, John Snow wrote:
> Signed-off-by: John Snow <js...@redhat.com>
> ---
> util/hbitmap.c | 22 +++++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/util/hbitmap.c b/util/hbitmap.c
> index 45d1725daf..0d6724b7bc 100644
> --- a/util/hbitmap.c
> +++ b/util/hbitmap.c
> @@ -777,7 +777,17 @@ void hbitmap_truncate(HBitmap *hb, uint64_t size)
>
> bool hbitmap_can_merge(const HBitmap *a, const HBitmap *b)
> {
> - return (a->size == b->size) && (a->granularity == b->granularity);
> + return (a->size == b->size);
> +}
> +
> +static void hbitmap_sparse_merge(HBitmap *dst, const HBitmap *src)
> +{
> + uint64_t offset = 0;
> + uint64_t count = src->orig_size;
> +
> + while (hbitmap_next_dirty_area(src, &offset, &count)) {
> + hbitmap_set(dst, offset, count);
This will not work, as hbitmap_next_dirty_area will return the same answer all
the time I think.
You need to update offset and count in a loop, like it is done in
backup_incremental_init_copy_bitmap.
> + }
> }
>
> /**
> @@ -804,6 +814,16 @@ bool hbitmap_merge(const HBitmap *a, const HBitmap *b,
> HBitmap *result)
> return true;
> }
>
> + if (a->size != b->size) {
> + if (a != result) {
> + hbitmap_sparse_merge(result, a);
> + }
> + if (b != result) {
> + hbitmap_sparse_merge(result, b);
> + }
> + return true;
> + }
> +
> /* This merge is O(size), as BITS_PER_LONG and HBITMAP_LEVELS are
> constant.
> * It may be possible to improve running times for sparsely populated
> maps
> * by using hbitmap_iter_next, but this is suboptimal for dense maps.
>
--
Best regards,
Vladimir
