Re: [Qemu-block] [PATCH v6 06/21] hbitmap: cache array lengths

2015-04-23 Thread Stefan Hajnoczi
On Fri, Apr 17, 2015 at 07:49:54PM -0400, John Snow wrote:
 As a convenience: between incremental backups, bitmap migrations
 and bitmap persistence we seem to need to recalculate these a lot.
 
 Because the lengths are a little bit-twiddly, let's just solidly
 cache them and be done with it.
 
 Reviewed-by: Max Reitz mre...@redhat.com
 Reviewed-by: Eric Blake ebl...@redhat.com
 Signed-off-by: John Snow js...@redhat.com
 ---
  util/hbitmap.c | 4 
  1 file changed, 4 insertions(+)

Reviewed-by: Stefan Hajnoczi stefa...@redhat.com


pgpJFTFui6cyd.pgp
Description: PGP signature


[Qemu-block] [PATCH v6 06/21] hbitmap: cache array lengths

2015-04-17 Thread John Snow
As a convenience: between incremental backups, bitmap migrations
and bitmap persistence we seem to need to recalculate these a lot.

Because the lengths are a little bit-twiddly, let's just solidly
cache them and be done with it.

Reviewed-by: Max Reitz mre...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Signed-off-by: John Snow js...@redhat.com
---
 util/hbitmap.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/util/hbitmap.c b/util/hbitmap.c
index ab13971..5b78613 100644
--- a/util/hbitmap.c
+++ b/util/hbitmap.c
@@ -90,6 +90,9 @@ struct HBitmap {
  * bitmap will still allocate HBITMAP_LEVELS arrays.
  */
 unsigned long *levels[HBITMAP_LEVELS];
+
+/* The length of each levels[] array. */
+uint64_t sizes[HBITMAP_LEVELS];
 };
 
 /* Advance hbi to the next nonzero word and return it.  hbi-pos
@@ -384,6 +387,7 @@ HBitmap *hbitmap_alloc(uint64_t size, int granularity)
 hb-granularity = granularity;
 for (i = HBITMAP_LEVELS; i--  0; ) {
 size = MAX((size + BITS_PER_LONG - 1)  BITS_PER_LEVEL, 1);
+hb-sizes[i] = size;
 hb-levels[i] = g_new0(unsigned long, size);
 }
 
-- 
2.1.0