From 8515efbef1759b9143f06e9722c8f4e145032181 Mon Sep 17 00:00:00 2001 From: John Snow Date: Fri, 17 Apr 2015 19:49:54 -0400 Subject: hbitmap: cache array lengths 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 Reviewed-by: Eric Blake Signed-off-by: John Snow Reviewed-by: Stefan Hajnoczi Message-id: 1429314609-29776-7-git-send-email-jsnow@redhat.com Signed-off-by: Stefan Hajnoczi Signed-off-by: Kevin Wolf --- util/hbitmap.c | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'util/hbitmap.c') 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); } -- cgit v1.1