[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 35/45] add hierarchical bitmap data type and
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH v2 35/45] add hierarchical bitmap data type and test cases |
Date: |
Wed, 24 Oct 2012 16:41:35 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 |
Am 26.09.2012 17:56, schrieb Paolo Bonzini:
> 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 <address@hidden>
> Signed-off-by: Paolo Bonzini <address@hidden>
I'll continue (or actually only start really) reviewing this tomorrow,
but let me ask one question now so that I won't forget it:
> +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;
Other places, for example HBitmap.size/count and the local pos variable
in hbitmap_iter_skip_words(), use uint64_t. Why is size_t here enough?
> +
> + /* 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];
> +};
Kevin
- Re: [Qemu-devel] [PATCH v2 35/45] add hierarchical bitmap data type and test cases,
Kevin Wolf <=